Repository navigation
chore: R-16 toolchain pin + reconciliation #79
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,91 @@ | ||
| name: Central Estate CI/CD Audit | ||
|
|
||
| on: | ||
| push: | ||
| branches: [ "main" ] | ||
|
Contributor
There was a problem hiding this comment. 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win Use the configured YAMLlint list format. YAMLlint reports an error for the spaces inside both branch lists. Change Also applies to: 7-7 🧰 Tools🪛 YAMLlint (1.37.1)[error] 5-5: too many spaces inside brackets (brackets) [error] 5-5: too many spaces inside brackets (brackets) 🪛 zizmor (1.29.0)[warning] 1-92: overly broad permissions (excessive-permissions): default permissions used due to no permissions: block (excessive-permissions) [warning] 3-7: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting (concurrency-limits) 🤖 Prompt for AI AgentsSource: Linters/SAST tools |
||
| pull_request: | ||
| branches: [ "main" ] | ||
|
|
||
| jobs: | ||
|
Contributor
There was a problem hiding this comment. 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: #!/bin/bash
set -euo pipefail
repo="$(gh repo view --json nameWithOwner -q '.nameWithOwner')"
gh api "repos/${repo}/actions/permissions/workflow"
# Expected: default_workflow_permissions is "read".
# Also verify each audit action's documented permissions before granting any scope above contents: read.Repository: hyperpolymath/proof-burrower Length of output: 408 🏁 Script executed: #!/bin/bash
set -euo pipefail
printf '%s\n' '--- repository convention scopes ---'
find /tmp/coderabbit-repo-knowledge/hyperpolymath-proof-burrower-de2b38c6 -maxdepth 2 -type f -name '*.md' -print
printf '%s\n' '--- relevant convention headers ---'
for f in /tmp/coderabbit-repo-knowledge/hyperpolymath-proof-burrower-de2b38c6/*/*.md; do
case "$f" in
*workflow*|*github*|*security*|*ci*|*action*) head -5 "$f";;
esac
done
printf '%s\n' '--- target workflow ---'
cat -n .github/workflows/main-estate-audit.yml
printf '%s\n' '--- workflow-linter relevant definitions ---'
sed -n '1,120p' .github/workflows/workflow-linter.yml
printf '%s\n' '--- checkout and permissions usage ---'
rg -n -C 3 'actions/checkout|persist-credentials|^[[:space:]]*permissions:|GITHUB_TOKEN|github-token' .github/workflowsRepository: hyperpolymath/proof-burrower Length of output: 40986 🌐 Web query:
💡 Result: In actions/checkout v4, the persist-credentials input defaults to true [1][2]. When this setting is enabled (the default), the authentication token or SSH key used to check out the repository is configured in the local git configuration [1][2]. This allows subsequent steps in your workflow to execute authenticated git commands directly [1][3]. The action automatically removes this token during the post-job cleanup process [1][3]. If you wish to opt-out of this behavior, you can explicitly set the input to false in your workflow file [1][3]: - uses: actions/checkout@v4 with: persist-credentials: false Citations:
Declare least-privilege token access and disable checkout credential persistence. The workflow linter rejects this file because it has no top-level 🧰 Tools🪛 zizmor (1.29.0)[warning] 1-92: overly broad permissions (excessive-permissions): default permissions used due to no permissions: block (excessive-permissions) 🤖 Prompt for AI AgentsSource: Linters/SAST tools |
||
| estate-audit: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v4 | ||
|
Contributor
There was a problem hiding this comment. 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: #!/bin/bash
set -euo pipefail
awk '
/^[[:space:]]+uses:/ &&
$0 !~ /@[a-f0-9]{40}([[:space:]]|$)/ {
print FNR ": " $0
}
' .github/workflows/main-estate-audit.yml
# Expected: no output after approved SHA pins are applied.Repository: hyperpolymath/proof-burrower Length of output: 2086 🏁 Script executed: #!/bin/bash
set -euo pipefail
printf '%s\n' '--- repository conventions ---'
find /tmp/coderabbit-repo-knowledge/hyperpolymath-proof-burrower-de2b38c6 -maxdepth 2 -type f -name '*.md' -print | sort
printf '%s\n' '--- workflow ---'
cat -n .github/workflows/main-estate-audit.yml
printf '%s\n' '--- workflow linter contract ---'
sed -n '1,110p' .github/workflows/workflow-linter.ymlRepository: hyperpolymath/proof-burrower Length of output: 8800 Pin every action reference to a commit SHA. The workflow linter rejects the 🧰 Tools🪛 zizmor (1.29.0)[warning] 13-13: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false (artipacked) [warning] 1-92: overly broad permissions (excessive-permissions): default permissions used due to no permissions: block (excessive-permissions) [warning] 10-92: overly broad permissions (excessive-permissions): default permissions used due to no permissions: block (excessive-permissions) [error] 13-13: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy) (unpinned-uses) 🤖 Prompt for AI AgentsSource: Linters/SAST tools |
||
|
|
||
| - name: Required Files Gate | ||
| uses: hyperpolymath/cicd-suite/actions/required-files-check@main | ||
|
|
||
| - name: Code Hygiene Gate | ||
| uses: hyperpolymath/cicd-suite/actions/code-hygiene-check@main | ||
|
|
||
| - name: Manifest Validation Gate | ||
| uses: hyperpolymath/cicd-suite/actions/manifest-check@main | ||
|
|
||
| - name: Idris2 ABI Purity Gate | ||
| uses: hyperpolymath/cicd-suite/actions/idris2-abi-check@main | ||
|
|
||
| - name: Zig Hexadeca API Gate | ||
| uses: hyperpolymath/cicd-suite/actions/zig-hexadeca-check@main | ||
|
|
||
| - name: Contractile Validation Gate | ||
| uses: hyperpolymath/cicd-suite/actions/contractile-validation-check@main | ||
|
|
||
| - name: Recipes Set Validation Gate | ||
| uses: hyperpolymath/cicd-suite/actions/recipes-set-check@main | ||
|
|
||
| - name: Affirmation Document Gate | ||
| uses: hyperpolymath/cicd-suite/actions/affirmation-check@main | ||
|
|
||
| - name: Academic Referencing Gate | ||
| uses: hyperpolymath/cicd-suite/actions/referencing-check@main | ||
|
|
||
| - name: Semantic Audit Gate | ||
| uses: hyperpolymath/cicd-suite/actions/semantic-audit-check@main | ||
|
|
||
| - name: SPDX License Gate | ||
| uses: hyperpolymath/cicd-suite/actions/spdx-license-check@main | ||
|
|
||
| - name: Proof Runner Gate | ||
| uses: hyperpolymath/cicd-suite/actions/proof-runner-check@main | ||
|
|
||
| - name: PRAT Testing Gate | ||
| uses: hyperpolymath/cicd-suite/actions/prat-check@main | ||
|
|
||
| - name: Panic Attack & Pons Gate | ||
| uses: hyperpolymath/cicd-suite/actions/custom-tools-check@main | ||
|
|
||
| - name: WWW & Well-Known Compliance Gate | ||
| uses: hyperpolymath/cicd-suite/actions/www-compliance-check@main | ||
|
|
||
| - name: BoJ Cartridge Validation Gate | ||
| uses: hyperpolymath/cicd-suite/actions/boj-cartridge-check@main | ||
|
|
||
| - name: Formatting Validation Gate | ||
| uses: hyperpolymath/cicd-suite/actions/formatting-check@main | ||
|
|
||
| - name: Accreditations & Badges Gate | ||
| uses: hyperpolymath/cicd-suite/actions/badges-check@main | ||
|
|
||
| - name: Metrics Extraction Gate | ||
| uses: hyperpolymath/cicd-suite/actions/metrics-check@main | ||
|
|
||
| - name: Linguist & Banned Languages Gate | ||
| uses: hyperpolymath/cicd-suite/actions/linguist-check@main | ||
|
|
||
| - name: Test & Benchmarks Dashboard Gate | ||
| uses: hyperpolymath/cicd-suite/actions/tests-benches-check@main | ||
|
|
||
| - name: Hosting & Site Status Gate | ||
| uses: hyperpolymath/cicd-suite/actions/hosting-check@main | ||
|
|
||
| - name: Git-Sea Analytics Gate | ||
| uses: hyperpolymath/cicd-suite/actions/gitsea-check@main | ||
|
|
||
| - name: Trust & Humans Validation Gate | ||
| uses: hyperpolymath/cicd-suite/actions/trust-humans-check@main | ||
|
|
||
| - name: Are We UnAPI Gate (Secret Scanning) | ||
| uses: hyperpolymath/cicd-suite/actions/secrets-check@main | ||
|
|
||
| - name: Reasonably Good Token Validation Gate | ||
| uses: hyperpolymath/cicd-suite/actions/vaulted-tokens-check@main | ||
|
Comment on lines
+11
to
+91
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,5 +9,5 @@ permissions: | |
| contents: read | ||
| jobs: | ||
| mirror: | ||
| uses: hyperpolymath/standards/.github/workflows/mirror-reusable.yml@7fdc2705df74b4e352d2a1cde3e87a5923fdf329 | ||
|
Contributor
There was a problem hiding this comment. 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- applicable repository conventions ---'
find /tmp/coderabbit-repo-knowledge/hyperpolymath-proof-burrower-de2b38c6 -maxdepth 2 -type f -name '*.md' -print
printf '%s\n' '--- workflow ---'
cat -n .github/workflows/mirror.yml
printf '%s\n' '--- repository references to the mirror workflow and secrets ---'
rg -n -C 3 'mirror-reusable|secrets: inherit|mirror' .github/workflows .github 2>/dev/null || true
printf '%s\n' '--- scoped convention and learning content ---'
for f in /tmp/coderabbit-repo-knowledge/hyperpolymath-proof-burrower-de2b38c6/*/*.md; do
printf '\n### %s\n' "$f"
cat "$f"
done
printf '%s\n' '--- called workflow at the pinned commit ---'
curl -fsSL 'https://raw.githubusercontent.com/hyperpolymath/standards/7fdc2705df74b4e352d2a1cde3e87a5923fdf329/.github/workflows/mirror-reusable.yml' | cat -nRepository: hyperpolymath/proof-burrower Length of output: 20849 🌐 Web query:
💡 Result: In GitHub Actions, secrets are not automatically passed to reusable workflows; they must be explicitly provided by the caller [1][2]. There are two primary methods for passing secrets: explicit mapping (named secret mapping) and the inherit keyword [3][4]. Explicit Mapping (Named Secrets) To pass specific secrets by name, you use the secrets keyword in your job definition and map individual secret names to values [3][4]. For this to work, the reusable workflow must declare these secrets in its on.workflow_call block [5][2]. Example of explicit mapping in the caller: jobs: call-workflow: uses: octo-org/example-repo/.github/workflows/reusable.yml@main secrets: MY_SECRET: ${{ secrets.MY_SECRET }} Example of declaration in the called (reusable) workflow: on: workflow_call: secrets: MY_SECRET: required: true Using secrets: inherit Alternatively, you can use the inherit keyword to automatically pass all secrets accessible to the caller (including repository, organization, and environment secrets) to the reusable workflow [3][6]. This keyword can only be used by workflows within the same organization or enterprise [3][7][8]. When using inherit, you do not need to define the secrets in the on.workflow_call block of the reusable workflow to access them [3][9]. Key Considerations - Security: Secrets are only passed to the directly called workflow [3][4]. In a chain (A > B > C), secrets must be passed from A to B, and then from B to C [3][8]. - Environment Secrets: Environment-level secrets are handled according to the environment defined in the called workflow; however, using secrets: inherit in the caller ensures the called workflow has access to the necessary context [9][6]. - Documentation: It is recommended to document expected secrets even when using inherit to avoid confusion if secrets are renamed or access permissions change [8]. Citations:
Declare and pass only the mirror secrets.
🧰 Tools🪛 zizmor (1.29.0)[warning] 12-12: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow (secrets-inherit) 🤖 Prompt for AI AgentsSource: Linters/SAST tools |
||
| secrets: inherit | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,10 +9,11 @@ on: | |
| permissions: | ||
| actions: read | ||
| contents: read | ||
| security-events: write | ||
| id-token: write | ||
|
Comment on lines
+12
to
+13
Contributor
There was a problem hiding this comment. 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- repository conventions ---'
find /tmp/coderabbit-repo-knowledge/hyperpolymath-proof-burrower-de2b38c6 -maxdepth 2 -type f -name '*.md' -print
printf '%s\n' '--- workflow ---'
cat -n .github/workflows/scorecard.yml
printf '%s\n' '--- relevant references ---'
rg -n -C 4 'permissions:|security-events|id-token|scorecard' .github/workflows/scorecard.yml /tmp/coderabbit-repo-knowledge/hyperpolymath-proof-burrower-de2b38c6 2>/dev/null || trueRepository: hyperpolymath/proof-burrower Length of output: 2348 🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- repository-wide workflow conventions ---'
cat /tmp/coderabbit-repo-knowledge/hyperpolymath-proof-burrower-de2b38c6/conventions/repo-wide.md
printf '%s\n' '--- machine-readable conventions ---'
cat /tmp/coderabbit-repo-knowledge/hyperpolymath-proof-burrower-de2b38c6/conventions/machine-readable.mdRepository: hyperpolymath/proof-burrower Length of output: 785 🌐 Web query:
💡 Result: In GitHub Actions, GITHUB_TOKEN permissions can be configured at the workflow level or the job level. When defined, these configurations override the repository's default settings [1][2]. Workflow-Level vs. Job-Level Permissions: - Workflow-level: Permissions defined at the top level of a workflow file apply to all jobs within that workflow [1][2]. - Job-level: Permissions defined within a specific job apply only to that job [1][2]. - Precedence: Job-level permissions do not merge with or append to workflow-level permissions; they completely replace them for that specific job [3][2]. If you define permissions at the job level, you must explicitly declare all required permissions, as any omitted permissions will be set to none [1][3]. Reusable Workflow Permissions: - Inheritance: A reusable workflow inherits the permissions granted to it by the job in the caller workflow that invokes it [4][5]. - Restrictions: Permissions cannot be elevated in a reusable workflow; they can only be maintained or downgraded [4][6]. This ensures that a called workflow cannot acquire higher privileges than those granted by its caller [4]. - Default behavior: If no permissions are specified in the calling job, the called workflow will use the repository's default GITHUB_TOKEN permissions [4]. Best Practices: - Apply the principle of least privilege by setting minimal permissions at the workflow level (e.g., contents: read) and escalating them only at the job level where strictly necessary [3][2]. - Explicitly define permissions in your workflows to avoid reliance on default settings, which can vary based on organization or repository policies [3][2][5]. Citations:
Keep elevated permissions at job scope.
🧰 Tools🪛 zizmor (1.29.0)[warning] 12-12: overly broad permissions (excessive-permissions): security-events: write is overly broad at the workflow level (excessive-permissions) [error] 13-13: overly broad permissions (excessive-permissions): id-token: write is overly broad at the workflow level (excessive-permissions) 🤖 Prompt for AI AgentsSource: Linters/SAST tools |
||
| jobs: | ||
| scorecard: | ||
| uses: hyperpolymath/standards/.github/workflows/scorecard-reusable.yml@7fdc2705df74b4e352d2a1cde3e87a5923fdf329 | ||
| permissions: | ||
| contents: read | ||
| security-events: write | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,11 @@ | ||
| [tools] | ||
| # = "Uncomment and customize for your project" | ||
| # = "rust nightly" | ||
| # = "just 1.40.0" | ||
| # = "nickel 1.10.0" | ||
| # = "gleam 1.8.0" | ||
| # = "elixir 1.18.0" | ||
| # = "erlang 27.2" | ||
| # = "zig 0.14.0" | ||
| # = "idris2 0.7.0" | ||
| rust = "nightly" | ||
|
Contributor
There was a problem hiding this comment. 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: mise exec -- rustup show active-toolchain
mise exec -- rustup component list --installed
mise exec -- rustup target list --installedRepository: hyperpolymath/proof-burrower Length of output: 284 🏁 Script executed: printf '%s\n' '--- repository conventions ---'
find /tmp/coderabbit-repo-knowledge/hyperpolymath-proof-burrower-de2b38c6 -maxdepth 2 -type f -name '*.md' -print
printf '%s\n' '--- toolchain files ---'
for f in .mise.toml rust-toolchain.toml rust-toolchain; do
if [ -f "$f" ]; then
echo "--- $f"
cat -n "$f"
fi
done
printf '%s\n' '--- mise references ---'
rg -n --hidden --glob '!target' --glob '!node_modules' '\bmise\b|RUSTUP_TOOLCHAIN|rust-toolchain' .github . 2>/dev/null | head -160Repository: hyperpolymath/proof-burrower Length of output: 1840 🏁 Script executed: cat /tmp/coderabbit-repo-knowledge/hyperpolymath-proof-burrower-de2b38c6/conventions/repo-wide.md
printf '%s\n' '--- tracked workflow files ---'
git ls-files '*workflow*' '.github' | head -120Repository: hyperpolymath/proof-burrower Length of output: 2732 🌐 Web query:
💡 Result: In the context of mise and Rust toolchain management, it is crucial to understand that mise operates by overriding rustup's native toolchain selection mechanism [1][2]. 1. Mise Precedence: When you use mise to manage Rust, it explicitly sets the RUSTUP_TOOLCHAIN environment variable in your shell [1][2]. Because RUSTUP_TOOLCHAIN is a high-priority override for rustup [3][4], it takes precedence over any rust-toolchain.toml file present in your project directory [5][6]. 2. Resolution Order: - Mise configuration (specifically the rust version defined in mise.toml) is the authoritative source for the toolchain version used in a shell managed by mise [2][5][6]. - Rustup's internal logic (which normally prioritizes rust-toolchain.toml) is effectively bypassed because mise forces the toolchain via the exported RUSTUP_TOOLCHAIN environment variable [1][2]. 3. Practical Implications: - If you have both a mise.toml and a rust-toolchain.toml, the version specified in mise.toml is what will be active in your terminal [5][6]. - To avoid discrepancies (such as CI using one version and your local shell using another), you must manually keep the version in mise.toml synchronized with the version in your rust-toolchain.toml [5][6]. - Mise does not automatically synchronize these files; it only reads the rust version from its own configuration to perform the installation and environment setup [2][7]. In summary, mise-managed shells will prioritize the mise configuration over native rustup discovery mechanisms [1][2][5]. If you rely on rustup natively (outside of a mise-activated shell), the rust-toolchain.toml file will resume its normal priority [3][4]. Citations:
🌐 Web query:
💡 Result: When using mise (formerly rtx) to manage Rust, it functions by leveraging rustup under the hood [1]. You do not need to manually manage the RUSTUP_TOOLCHAIN environment variable for routine usage; mise handles this automatically [1]. Key aspects of how mise manages Rust toolchains include: 1. Automatic Toolchain Management: When you specify a rust version in your mise configuration (e.g., in your mise.toml file), mise ensures the requested toolchain, components, and targets are installed via rustup [1]. 2. RUSTUP_TOOLCHAIN Integration: mise sets the RUSTUP_TOOLCHAIN environment variable to the requested version when it activates the tool, allowing rustup to correctly point to the toolchain managed by mise [1]. 3. Directory Configuration: By default, mise uses the standard ~/.rustup and ~/.cargo directories [1]. If you prefer to keep your mise-managed Rust installations separate from other rustup installations, you can configure the home directories using the MISE_RUSTUP_HOME and MISE_CARGO_HOME environment variables, or by setting these in your mise configuration under [env] [1]. 4. Compatibility with Existing Rustup: If you have an existing rustup installation managed by a package manager (like Homebrew or APT), mise can utilize it, provided the necessary binaries (rustup, cargo, rustc) are in your PATH [1]. However, if you explicitly set a Rust or Cargo home directory, mise will switch to its own managed rustup initialization [1]. For detailed configuration, you can set tool-specific options in your mise.toml, such as setting a custom rust.rustup_home [1]. Citations: Align When 🤖 Prompt for AI AgentsSource: MCP tools |
||
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.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Add the required SPDX header.
The workflow security linter fails because this is not the first line:
# SPDX-License-Identifier: MPL-2.0. Add the header beforename:.🧰 Tools
🪛 GitHub Actions: Workflow Security Linter / 0_lint-workflows.txt
[error] 1-1: SPDX license header check failed: the file is missing '# SPDX-License-Identifier: MPL-2.0' as its first line. The validation command exited with code 1.
🪛 GitHub Actions: Workflow Security Linter / lint-workflows
[error] 1-1: SPDX license header check failed. Add '# SPDX-License-Identifier: MPL-2.0' as the first line.
🪛 zizmor (1.29.0)
[warning] 1-92: overly broad permissions (excessive-permissions): default permissions used due to no permissions: block
(excessive-permissions)
🤖 Prompt for AI Agents
Source: Pipeline failures