[codex] Fix compact reset boundaries #14
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,55 @@ | ||
| name: health | ||
|
|
||
| on: | ||
| pull_request: | ||
| push: | ||
| branches: | ||
| - main | ||
| - "release/**" | ||
|
|
||
| permissions: | ||
| contents: read | ||
|
|
||
| concurrency: | ||
| group: ${{ github.workflow }}-${{ github.ref }} | ||
| cancel-in-progress: true | ||
|
|
||
| jobs: | ||
| repo-health: | ||
| name: Repository Health Checks | ||
| runs-on: ubuntu-24.04 | ||
| timeout-minutes: 60 | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 | ||
| with: | ||
| persist-credentials: false | ||
|
|
||
| - name: Set up Node | ||
| uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e | ||
| with: | ||
| node-version: "22" | ||
|
Comment on lines
+23
to
+31
There was a problem hiding this comment. 🧩 Analysis chain🏁 Script executed: cat .github/workflows/health.ymlRepository: eternalwaitt/eternal-stack Length of output: 1004 🌐 Web query:
💡 Result: Pinning GitHub Actions to a full-length commit SHA is the only way to ensure the immutability of an action and protect against supply chain attacks involving mutable references [1][2][3]. Why Pinning by SHA is Required: Git tags (like v4) and branch names (like main or master) are mutable pointers [4][5][6]. They can be force-pushed or updated at any time by repository maintainers or attackers who compromise a maintainer's account [7][8][9]. When you reference an action by a tag, your workflow will automatically execute whatever code the tag currently points to, making you vulnerable to malicious code injection if that tag is retargeted [10][5][11]. Best Practices for Security: - Use Full 40-Character Commit SHAs: Always use the complete 40-character SHA [12][11]. Never use shortened SHAs or mutable tags [12][3]. - Maintain Readability with Comments: Because SHAs are not human-readable, append the original tag or version as a comment in your YAML file [6][11]. This allows automated tools like Dependabot or Renovate to identify which version the SHA corresponds to and suggest updates [13][2][6]. Example: - uses: actions/checkout@11bd719 # v4.2.2 - Automate Updates: Use dependency management tools such as Dependabot or Renovate to keep your pinned SHAs up to date [13][6]. They can be configured to automatically create pull requests when a new tag is released, ensuring you receive security patches without manually managing the SHAs [13][6]. - Enforce via Policy: GitHub allows organization and repository-level policies that can mandate the use of full-length commit SHAs, causing any workflows that use mutable references to fail [1][7][6]. - Use Audit Tools: Implement automated checks in your CI/CD pipeline, such as zizmor or custom scripts, to scan your workflow files and fail builds that contain unpinned actions [12][6][11]. Verified creator badges on GitHub Marketplace provide some assurance, but they do not eliminate the risk of account compromise or malicious tag updates; SHA pinning remains the definitive security control [1][8]. Citations:
🌐 Web query:
💡 Result: Setting persist-credentials to false in actions/checkout is considered a security best practice to minimize the exposure of repository authentication tokens during a workflow execution [1][2][3]. By default, actions/checkout is set to persist-credentials: true, which causes the action to configure the local Git environment with the provided token (typically GITHUB_TOKEN or a custom SSH key) [4][1][5]. This makes the credentials available to any subsequent steps in the same job [1][2][6]. While the token is removed during post-job cleanup, setting this to false prevents the token from being written to the Git configuration on disk in the first place, thereby reducing the risk of accidental exposure via logs, artifacts, or unauthorized access by malicious actions within the workflow [1][5][7]. It is important to note the following context: 1. How it works: When persist-credentials is true, the action writes the credentials to the local git config [4][2]. In recent versions (starting with v6), this storage location was moved to a restricted directory ($RUNNER_TEMP) to reduce the risk of accidental leaks through artifact creation [4][8][7]. 2. Limitations: Setting persist-credentials to false only affects the automatic configuration of the local git environment [2][9]. It does not revoke the job's access to the GITHUB_TOKEN, which remains available to the workflow through other standard mechanisms [6][7]. If a subsequent action (such as a git-auto-commit action) requires authenticated git operations, it may fail unless you manually reconfigure the credentials or provide them via other means [3]. 3. Recommendation: You should explicitly set persist-credentials: false unless your workflow specifically requires authenticated git commands (like pushing commits back to the repository) [1]. Even then, consider whether there are more secure ways to provide those credentials only to the specific steps that require them [2][6]. Example configuration: - uses: actions/checkout@v4 with: persist-credentials: false Citations:
🌐 Web query:
💡 Result: In actions/setup-node, the package-manager-cache input controls the automatic caching feature for npm [1][2]. By default, this input is set to true, which enables automatic caching if your package.json file includes a devEngines.packageManager or a top-level packageManager field set to npm, provided no explicit cache input is specified [1][2][3]. Setting package-manager-cache to false disables this automatic caching behavior [1][4]. GitHub officially recommends setting package-manager-cache: false in workflows that involve elevated privileges or access to sensitive information, such as those used for package publishing, when caching is not strictly required for performance [1][5][2]. This guidance is provided as a security measure to mitigate risks like cache poisoning, where an attacker might attempt to inject malicious code or intercept sensitive data (including tokens) via the cached dependency directory [5]. If a workflow is designed to run with elevated permissions—or if you simply want to avoid the potential security surface area of automated caching—explicitly disabling it is considered a best practice [1][6]. For example, to disable it in your GitHub Actions workflow: steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v6 with: node-version: '24' package-manager-cache: false # Disables automatic npm caching [7] Citations:
Pin action revisions and harden checkout defaults. Lines 18 and 21 use mutable tags ( 🧰 Tools🪛 zizmor (1.25.2)[warning] 17-18: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false (artipacked) [error] 18-18: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy) (unpinned-uses) [error] 21-21: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy) (unpinned-uses) [error] 21-21: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default (cache-poisoning) 🤖 Prompt for AI AgentsSource: Linters/SAST tools |
||
| # No package install runs in this job; keep setup-node package-manager caching disabled. | ||
| package-manager-cache: false | ||
|
|
||
| - name: Install CLI dependencies | ||
| run: | | ||
| sudo apt-get update | ||
| sudo apt-get install -y jq fd-find ripgrep shellcheck python3.12 | ||
| sudo ln -sf "$(command -v fdfind)" /usr/local/bin/fd | ||
| sudo ln -sf "$(command -v python3.12)" /usr/local/bin/python3 | ||
|
|
||
| - name: Validate generated rule exports | ||
| run: node scripts/sync-rule-exports.mjs --check | ||
|
|
||
| - name: Hook tests | ||
| run: tests/test-hooks.sh | ||
|
|
||
| - name: Workflow tool tests | ||
| run: tests/test-workflow-tools.sh | ||
|
|
||
| - name: Install and rollback tests | ||
| run: tests/test-install.sh | ||
|
|
||
| - name: Doctor | ||
| run: scripts/doctor.sh --jobs 4 | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1 @@ | ||
| 0.5.2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧹 Nitpick | 🔵 Trivial | ⚡ Quick win
Add workflow-level concurrency control.
Without
concurrency, rapid pushes can run overlapping full health jobs for the same ref, wasting CI time and increasing queue contention.🔧 Suggested diff
on: pull_request: push: branches: - main - "release/**" +concurrency: + group: health-${{ github.workflow }}-${{ github.ref }} + cancel-in-progress: true + permissions: contents: read📝 Committable suggestion
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 3-8: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
🤖 Prompt for AI Agents
Source: Linters/SAST tools