Repository navigation
chore(deps): bump rustls from 0.23.37 to 0.23.45 in /rhodium-standard-repositories/satellites/rsr-certifier in the cargo group across 1 directory - #1206
Merged
hyperpolymath merged 1 commit intoOct 8, 2026
Conversation
Bumps the cargo group with 1 update in the /rhodium-standard-repositories/satellites/rsr-certifier directory: [rustls](https://github.com/rustls/rustls). Updates `rustls` from 0.23.37 to 0.23.45 - [Release notes](https://github.com/rustls/rustls/releases) - [Changelog](https://github.com/rustls/rustls/blob/main/CHANGELOG.md) - [Commits](rustls/rustls@v/0.23.37...v/0.23.45) --- updated-dependencies: - dependency-name: rustls dependency-version: 0.23.45 dependency-type: indirect dependency-group: cargo ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Contributor
|
Important Review skippedBot user detected. To trigger a single review, invoke the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
K9 contract conformancerun https://github.com/hyperpolymath/standards/actions/runs/37767749934 K9 normative contract typecheckK9 contract self-testK9 conformance fixturesK9 corpus conformance (L2) |
|
hyperpolymath
approved these changes
Oct 8, 2026
hyperpolymath
deleted the
dependabot/cargo/rhodium-standard-repositories/satellites/rsr-certifier/cargo-e3be83c1e1
branch
October 8, 2026 11:06
This was referenced Oct 8, 2026
hyperpolymath
added a commit
that referenced
this pull request
Oct 9, 2026
…ion (#1210) ## Summary `tag-ruleset-canon.yml` mints one GitHub App installation token per owner (`RULESET_APP_ID`, #1208). `scripts/apply-tag-ruleset-canon.sh` still assumed a PAT, so **both workflow steps would have failed on their first App run**. This PR makes the applier work under an installation token and leaves PAT behaviour unchanged. Three defects are fixed: 1. **hyperpolymath step: `user/repos` under an App token.** That endpoint needs a user identity, so it answers an installation token (`ghs_…`) with `403 Resource not accessible by integration`. Under `set -e` the run died before it examined any repository. Under an installation token the applier now lists **`installation/repositories`** (private repos included, archived ones dropped). If that listing fails, the run dies and names the endpoint. 2. **metadatastician step: write probe outside the installation.** The apply-mode write probe always self-PUT `GITHUB_REPOSITORY` (`hyperpolymath/standards`). An installation on metadatastician cannot write that repo, so a capable credential got a **false exit 3** ("credential cannot WRITE rulesets"). Under an installation token the probe now self-PUTs a repository-level tag ruleset **inside its own installation**. It skips org-inherited rulesets, because a per-repo PUT of those 404s (#1032). A credential that really cannot write still stops the run with exit 3. 3. **`ESTATE_ORGS=''` meant metadatastician.** The hyperpolymath step sets `ESTATE_ORGS: ''`, but `${ESTATE_ORGS:-metadatastician}` treated the empty string as unset. That step would therefore also sweep metadatastician repos its token cannot write. It is now `${ESTATE_ORGS-metadatastician}`: an explicit empty value means no orgs, and the default still applies when the variable is unset. **Unchanged under a PAT** (the `ESTATE_ADMIN_TOKEN` fallback): targets come from `user/repos` and the probe self-PUTs `GITHUB_REPOSITORY`. The workflow file is **not** touched. No tracking issue. This implements the owner's ruling of 2026-10-08: "Fix in a standards PR now". ## Type of change - [x] 🐛 Bug fix (non-breaking change that fixes an issue). Under a PAT nothing changes. Under an App token the applier now runs where before it crashed. - [ ] ✨ New feature. No new capability; this makes the existing App path work. - [ ] 💥 Breaking change. The one behaviour change is that an explicit `ESTATE_ORGS=''` now means no orgs. The only caller that sets it to `''` is the hyperpolymath step of `tag-ruleset-canon.yml`, which wants exactly that. - [ ] 🕳️ Soundness fix. The ruleset canon and the convergence logic are unchanged. - [ ] 📖 Documentation. Only the script's header comment changes, to describe `--skip-user` and `ESTATE_ORGS` under an App token. - [ ] 🧹 Refactor / tech debt. Not behaviour-preserving (see Bug fix). - [ ] ⚡ Performance. Not applicable. - [x] 🔧 Build / CI / tooling. An estate maintenance script and a new test for it. ## 📌 New pins - **Head SHA: `e39d890c6de1f56faa6bdba1f02aca20234f4aed`** - None. No `uses:` SHA, `actions.lock` entry, lockfile record or container digest is added or changed. No workflow file is touched. ## How has this been verified? All commands were run in the worktree on Debian 13 (WSL2). - **New `scripts/tests/apply-tag-ruleset-canon-test.sh` → `passed=14 failed=0`.** It runs the applier against a stub `gh` that serves fixtures and refuses what GitHub refuses: - `ghs_` on `user/repos` → 403; - an installation token writing outside its installation → 403; - a per-repo PUT of an org-inherited ruleset → 404. - **Planted positives (3):** the stub is shown to refuse each of those, so no case passes vacuously. - **Cases (6):** - App token with `ESTATE_ORGS=''`: targets are exactly the installation's non-archived repos, both CONVERGED, rc 0, and `user/repos` is never called. - PAT: `user/repos`. - PAT probe: still `GITHUB_REPOSITORY`. - A failed installation listing: non-zero rc, no report lines, the endpoint named. - Org App token in apply mode with `GITHUB_REPOSITORY=hyperpolymath/standards`: exactly one probe PUT, to the repo-level ruleset inside the installation. The org-inherited repo listed first is skipped and reported ORG-INHERITED. rc 0. - Write-denied org token: **still exit 3**. - **Mutants (4), each `bash -n`-checked and each killed:** - the `ghs_*` detection disabled, killed by 2 cases; - `${ESTATE_ORGS:-…}` restored; - the `source_type == "Repository"` filter removed from the probe; - the listing failure swallowed. - **The `origin/main` applier through the same harness → 5 cases failed:** - App token: rc=1 on the `user/repos` 403, as was the failed-listing case; - PAT with `ESTATE_ORGS=''`: `metadatastician/delta` was swept; - org probe: false rc=3, no write attempted. - **`bash tests/test_tag_ruleset_canon.sh` → `passed=31 failed=0`** (the existing structural guards, properties 1–14). - **`shellcheck`** on both files → rc 0. One `SC2016` is disabled on a single line, with a reason: the `${…}` there is sed text to match. - **`.githooks/docstring-scan.sh --worktree --check` → `functions=17 documented=17 coverage=100.00%`.** - **`bash scripts/run-shell-test-suite.sh` → 80 of 82 test files pass.** The 2 failures are **pre-existing on `main`**: `scripts/tests/build-registry-test.sh` (2 ❌) and `scripts/tests/build-scorecards-test.sh` (10 ❌) fail identically in a clean detached worktree of `origin/main` `900c42c7`. This PR touches neither generator nor either test. - **Pre-commit hooks:** all passed (gitleaks, SPDX, sha-pins, actions-lock, permissions, codeql, bot-directives). - **CI on this head** (Self Test run 37861614216): `scripts/tests/apply-tag-ruleset-canon-test.sh` → `passed=14 failed=0`. The run reports `2 of 82 test file(s) failed`, and they are the same two pre-existing files. **Horizon:** this is a local stub of GitHub's behaviour, not a live run. The live acceptance run is the next step. It needs the ruleset App to be created and installed on both owners, and `RULESET_APP_ID` / `RULESET_APP_PRIVATE_KEY` to be set on this repo. Then `tag-ruleset-canon` is dispatched with `apply=false`. ## Checklist - [x] My commits are **signed**: one commit, `git log --show-signature` → `G`, ED25519. - [x] I ran the project's own checks/tests locally and they pass, apart from the 2 test files that fail identically on `main` (see above). - [x] New files carry the correct `SPDX-License-Identifier`: the new test is `MPL-2.0`. No existing file was relicensed. - [x] Docs are updated, and no public claim now overstates what the code does. The script header now says what `--skip-user` and `ESTATE_ORGS=''` do under an App token. - [x] I have not introduced a soundness hole. The probe still refuses a credential that cannot write (shown by the write-denied case), and the convergence and comparison logic is untouched. ## Notes for reviewers - **Why detect `ghs_` rather than try `user/repos` and fall back?** A 403 from `user/repos` is the same 403 a mis-scoped PAT gets. A fallback would quietly turn a broken PAT into "list whatever installation/repositories says". The token prefix is the one unambiguous signal. `GITHUB_TOKEN` is also `ghs_`. Its installation lists only this repo, so in apply mode the write probe PUTs here, gets 403 (no `administration:write`) and stops the run with exit 3, as before. In a dry run it would report on this one repo only. - **`list_installation_repos` runs at most once.** Both the probe and the enumeration need it. It is called in the main shell, never inside `$(…)`, so the once-only flag survives. - **Out of scope:** `scripts/apply-workflow-pins-remote.sh` lists targets with `users/<owner>/repos`, which returns public repos only. That is recorded as a finding, not fixed here. - **Red check deferred:** `Registry + topology in sync` also fails on `main` at `900c42c7`. It has been red since `bbcc722b` (#1206). This PR touches neither the registry nor its generator. Tracked by #1161 §2, which has acceptance criteria. - **Red check deferred:** `Repo self-tests` also fails on `main` at `900c42c7` (Self Test run 37770790241). The same two files fail there and on this head: `scripts/tests/build-registry-test.sh` and `scripts/tests/build-scorecards-test.sh`, for the cause in the row above (`REGISTRY.a2ml` drift). Tracked by #1161 §2. The fix, either regenerating the registry or retiring the check along with `.a2ml`, is the owner's ruling, so this PR does not regenerate the registry. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_015bTuGfwCcvjrmNFejydTML Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
hyperpolymath
added a commit
that referenced
this pull request
Oct 9, 2026
…#1209) ## Summary The "Check locked or SHA-pinned actions" step (job **Actions lockfile verify**) runs under the runner's default `bash -e {0}`. `set -uo pipefail` does not clear `-e`. So the bare gate call followed by `rc=$?` never reaches the capture. A gate exit 3 (missing lock) kills the step before the shrink-only ledger `.machine_readable/lock-allow.txt` is read. The ledger has been unreachable since 4f7f02c (#899, 2026-09-22). Since `ENFORCE_FROM` 2026-10-01, a lockless repository on the ledger and pinned at or after 4f7f02c is red on this job, even though the ledger was written to excuse it. Found on hyperpolymath/jaffascript#73: the job log shows the gate's exit-3 error, then `Process completed with exit code 3`, and neither ledger line is printed. The fix is `rc=0; bash gate || rc=$?`. This file already uses the same idiom at the two other exit-status captures that are not under `set +e` (the grep scan and the launcher-currency check). I checked every other `rc=$?` / `STATUS=$?` capture in `.github/workflows/` on main: all of them sit under `set +e`, so this is the only instance. ## Type of change - [x] 🐛 Bug fix (non-breaking change that fixes an issue) - [ ] ✨ New feature — no - [ ] 💥 Breaking change — no. A repository that is not on the ledger keeps its exact exit code (3 or 1). - [ ] 🕳️ Soundness fix — not a checker false-negative. It removes a false *positive*: debt that is ledgered was reported as a violation. - [ ] 📖 Documentation — no - [ ] 🧹 Refactor / tech debt — no - [ ] ⚡ Performance — no - [x] 🔧 Build / CI / tooling ## 📌 New pins - Head SHA: **`2029699dd59fc9b34ca3f6a093132b47dbf671e2`** - No `uses:` refs, `actions.lock` entries, lockfile records or container digests are added or changed. - Callers reach this fix only by bumping their `governance-reusable.yml@<sha>` pin to the merge commit. ## How has this been verified? CI on this PR **cannot** exercise the changed path. Standards carries an `actions.lock`, so its own gate exits 0 and the ledger branch is never reached. I verified it locally instead. Method: I extracted the step's `run:` script from this branch and from `origin/main` with `yq '.jobs[].steps[]? | select(.name == "Check locked or SHA-pinned actions") | .run'`. I ran each under `/usr/bin/bash -e`, as the runner does, in a disposable directory holding: - a caller's `.github/workflows/` - `.standards-lock/{scripts,.machine_readable}` copied from this branch `GITHUB_REPOSITORY` varied per row: | variant | caller workflows | repository | rc | ledger branch | |---|---|---|---|---| | unfixed | block YAML (jaffascript#73) | hyperpolymath/jaffascript (ledger line 117) | 3 | never reached | | unfixed | block YAML | hyperpolymath/zz-not-ledgered | 3 | never reached | | unfixed | KYAML (jaffascript main 589e1be) | hyperpolymath/jaffascript | 1 | never reached | | **fixed** | block YAML | hyperpolymath/jaffascript | **0** | `::notice::` … LEDGERED | | **fixed** | block YAML | hyperpolymath/zz-not-ledgered | **3** | "NOT among them" | | **fixed** | KYAML | hyperpolymath/jaffascript | **1** | "NOT among them" (exit 1 is not ledgerable) | Also run: - `actionlint`: 14 findings before and after. The sets are identical once line numbers are stripped; all predate this PR (`job.workflow_sha` unknown to the local actionlint, SC2086 info at line 45). - Pre-commit hooks passed: SPDX, workflow SHA-pinning, lockfile coverage, permissions. ## Checklist - [x] My commits are **signed** (`git commit -S`): `git log --format=%G?` reports `G`. - [x] I ran the project's own checks/tests locally and they pass: the pre-commit suite passed, and the planted-control matrix is above. - [ ] New files carry the correct `SPDX-License-Identifier` — not applicable: no new files. - [x] Docs are updated, and no public claim now overstates what the code does. The new comment states the mechanism. - [x] I have not introduced a soundness hole. Not-ledgered repos and exit-1 violations keep their exit codes (rows 5 and 6). ## Notes for reviewers - I kept this to one concern. The same gate is also blind to KYAML: `scripts/check-actions-lock-gate.sh:66-68` does not accept a quoted `uses: "…@<sha>",`, so a KYAML workflow returns exit 1. That is logged as a separate finding (the KYAML shim work in AGENTS.md §2a), not fixed here. - This file stays in block YAML: per #1207, standards' own gates do not read KYAML yet. - **Red check deferred:** `Registry + topology in sync` fails on `main` too (every Registry Verify run since `bbcc722b`, the dependabot rustls bump #1206, 2026-10-08 11:06Z). It is unrelated to this one-file workflow change. Tracked by #1161 §2, which has acceptance criteria. - **Red check deferred:** `Repo self-tests` fails on `main` too, at `900c42c7`, `a695e379` and `bbcc722b` (Self Test run 37770790241 on `900c42c7`). It was green at `d8a90cf8`. The same two files fail there and on this head: `scripts/tests/build-registry-test.sh` and `scripts/tests/build-scorecards-test.sh`. Both have the same cause as the row above. The registry test reports `DRIFT: .machine_readable/REGISTRY.a2ml is stale`. The 3 "broken passes" in the scorecards test (`component-readiness-grades/M3`, `estate-constitution/M2`, `neurosym-a2ml/M5`) all run `bash scripts/build-registry.sh --check`. Tracked by #1161 §2. Its fix (regenerate, or retire the check along with `.a2ml`) is the owner's ruling, so this PR does not regenerate the registry. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01GpUzjdhWFi26k6s7AWxYcf Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
7 of 13 tasks
hyperpolymath
added a commit
that referenced
this pull request
Oct 9, 2026
…1211) ## Summary `scripts/apply-workflow-pins-remote.sh` lists its targets with `users/<owner>/repos`, falling back to `orgs/<owner>/repos`. Both endpoints answer a GitHub App installation token (`ghs_…`) with **public repositories only**. So once `APP_ID` is set, the private repositories the applier App is installed on, and can write, are **never audited and never re-pointed**. This PR adds them. 1. **Under a `ghs_` token, the installation's own repositories are added to the public listings.** They come from `installation/repositories`, with archived ones dropped and the list filtered to `--owners`. They are added, not substituted: `GITHUB_TOKEN` is `ghs_` too, and its installation is this one repository. Replacing the listing would shrink the scheduled audit census, which runs on `GITHUB_TOKEN` while no App is configured, to `hyperpolymath/standards` alone. 2. **Enumeration now fails closed.** `list_repos` returns 1 and prints nothing when the installation listing fails, or when an owner's `users/` and `orgs/` listings both fail. `main` then stops before writing a census and says the enumeration failed. Before this, the second listing's stderr went to `/dev/null` and its exit status was ignored, so a rate-limited owner silently contributed zero repositories. That is the same fail-open `fetch_workflows` was cured of on 2026-10-02. **Under a PAT nothing changes:** the public listings, and `installation/repositories` is never called. The workflow file is **not** touched. No tracking issue. This is the bug-fix half of the owner's request "push the f88b721 with bug fix" (dev-notes `f88b721` recorded the finding). ## Type of change - [x] 🐛 Bug fix (non-breaking change that fixes an issue). Under an App token the census now includes the installation's private repositories. Under a PAT or `GITHUB_TOKEN` the public census is unchanged. - [ ] ✨ New feature. No new capability; the App path now sees what the App can write. - [ ] 💥 Breaking change. One behaviour changes on purpose: a run whose enumeration fails now exits 1 instead of reporting a partial census. That is the intended fail-closed behaviour, not a break of any caller. - [ ] 🕳️ Soundness fix. The classifier and the rewrite logic are untouched. The fail-closed enumeration does remove a false "nothing to do" for a rate-limited owner, but it is listed under Bug fix. - [ ] 📖 Documentation. Only `list_repos`'s own docstring is new. - [ ] 🧹 Refactor / tech debt. Not behaviour-preserving (see Bug fix). - [ ] ⚡ Performance. Under an App token there is one extra paginated listing per run; under any other token there is none. - [x] 🔧 Build / CI / tooling. An estate maintenance script and its test suite. ## 📌 New pins - **Head SHA: `1ba3f5b0670c475506db73e214da20058d59191f`** - None. No `uses:` SHA, `actions.lock` entry, lockfile record or container digest is added or changed. No workflow file is touched. ## How has this been verified? All local commands were run in the worktree on Debian 13 (WSL2). - **`bash tests/test_apply_workflow_pins_remote.sh` → 41 PASS, `RESULT: all checks passed`, rc 0.** The new section 4 runs `list_repos`, and `main` end to end, against a stub `gh` that serves listing fixtures with real `jq` and refuses `installation/repositories` to a non-`ghs_` token. - **Planted positives (2):** the stub refuses `installation/repositories` to a PAT, and fails a flagged `users/` listing. So no fail-closed case can pass because nothing ever failed. - **Cases (9):** - App token: exactly `hyperpolymath/priv-b`, `hyperpolymath/pub-a` and `metadatastician/pub-c`. The private installation repo is included, both archived repos are dropped, and `pub-a` (public and in the installation) appears once. - `GITHUB_TOKEN`-shaped `ghs_` token whose installation is `hyperpolymath/standards`: the public census survives alongside it. - PAT: the public listings only, and `installation/repositories` is absent from the call log. - `--owners metadatastician` under an App token on hyperpolymath: no hyperpolymath repo leaks in. - A `users/` 404 falls back to `orgs/`. - Failed installation listing: rc 1, nothing printed, and the endpoint is named. - Both public listings fail for one owner: rc 1, nothing printed, and the owner is named. - `main`, App token: the census row `hyperpolymath/priv-b ci.yml FRESH` is present. - `main`, failed enumeration: rc 1, no census, "repository enumeration failed" on stderr. - **Mutants (6).** Each one is checked to have changed the file and to parse (`bash -n`), and each is killed: - `ghs_` detection disabled; - the installation listing replacing the public one (killed by the `GITHUB_TOKEN` case); - dedupe removed; - the owner filter dropped; - the installation-listing failure swallowed; - the public-listing failure swallowed. - **The `origin/main` applier through the same section 4 → 7 of its 12 behaviour checks fail.** - Under an App token `priv-b` is missing. - A failed installation listing returns rc 0 with the public repos. - A rate-limited owner yields a partial list, which `main` would have accepted. - The end-to-end census lacks the private repo. - A failed enumeration is not reported as one. - **Live audit run on this head, under `GITHUB_TOKEN`:** [run 37865067072](https://github.com/hyperpolymath/standards/actions/runs/37865067072), dispatched with `mode=audit` and `limit=2`. The run succeeded. The cred step logged "AUDIT-ONLY: no App credential; census will run on GITHUB_TOKEN". The applier enumerated with no FATAL, walked 2 repos and reported `BEHIND 4`. - **`shellcheck`** on both files → 11 findings on this branch and 11 on `origin/main`, and the two sets are identical (compared with line numbers stripped). This PR adds none. Two new `SC2016` disables carry a reason: `$1` and `$2` there are expanded by an inner `bash -c`. - **`.githooks/docstring-scan.sh --worktree --check` → `functions=17 documented=17 coverage=100.00%`.** - **`bash scripts/run-shell-test-suite.sh` → 79 of 81 test files pass.** The 2 failures are **pre-existing on `main`**: `scripts/tests/build-registry-test.sh` and `scripts/tests/build-scorecards-test.sh` fail the same way on `900c42c7`. This PR touches neither generator nor either test. - **Pre-commit hooks:** all passed (gitleaks, SPDX, sha-pins, actions-lock, permissions, codeql, bot-directives). - **PR CI on this head** (check-runs read with `--paginate`): 66 runs. 52 success, 12 skipped, 2 failure. - The 3 required contexts passed: `governance / Actions lockfile verify`, `uses ⊆ actions.lock` and `scan / gitleaks`. - In Repo self-tests, `tests/test_apply_workflow_pins_remote.sh` PASSes. The job reports "2 of 82 test file(s) failed": build-registry and the Wave-3 scorecard test, the same two pre-existing failures. The count is 82 because the merge ref includes #1210's new test. - **Code scanning:** on the PR merge ref, CodeQL (actions), CodeQL (javascript-typescript) and Hypatia each analysed `408ef607` and returned 0 results. The open alerts on the PR ref minus those on `main` form the **empty set**. All 10 open alerts on `main` are Scorecard findings, and Scorecard does not run on PRs. **Horizon:** - The stub cases model GitHub's documented behaviour; they are not a live App run. The live run above proves that the `GITHUB_TOKEN` audit path still works on this head. It does **not** show that `installation/repositories` was called, because the log masks the token: that rests on `GITHUB_TOKEN` carrying the documented `ghs_` prefix. - The App path itself gets its live acceptance run once `APP_ID` and `APP_PRIVATE_KEY` are set and the applier App is installed. ## Checklist - [x] My commits are **signed**: one commit, `git log --show-signature` → `G`, ED25519. - [x] I ran the project's own checks/tests locally and they pass, apart from the 2 test files that fail the same way on `main` (see above). - [x] New files carry the correct `SPDX-License-Identifier`. No new files; both changed files keep their existing `MPL-2.0` header, and no file was relicensed. - [x] Docs are updated, and no public claim now overstates what the code does. `list_repos`'s new docstring says what each credential sees and why the listings are unioned. The workflow's comments are unchanged and remain accurate. - [x] I have not introduced a soundness hole. Enumeration is now stricter (fail-closed), and the classifier, the rewrite and `fetch_workflows` are untouched. ## Notes for reviewers - **Why union and not replace?** #1210 could replace `user/repos` with `installation/repositories` because `user/repos` 403s for any installation token. Here `users/<o>/repos` succeeds under `ghs_` and merely under-reports. Replacing it would turn today's `GITHUB_TOKEN` audit into a census of one repository. The `replace_not_union` mutant exists to keep that from regressing. - **Out of scope, recorded in dev-notes `inbox/findings.md`:** - The workflow mints `tok-org` (the applier App scoped to metadatastician) and never uses it; L126 passes only `tok-user || GITHUB_TOKEN`. Even after this PR, metadatastician's **private** repos stay invisible, and `--fix` writes to metadatastician repos fall outside the hyperpolymath installation. - The fix is one applier step per owner, each with its own token. That is a workflow edit, held until this repo's gates read KYAML (AGENTS.md §2a). - A PAT also lists public repos only. That is unchanged here. - **Red check deferred:** `Registry + topology in sync` also fails on current `main`, `2e12b312` (measured with check-runs `--paginate` at PR open). It has been red since `bbcc722b` (#1206). This PR touches neither the registry nor its generator. Tracked by #1161 §2, which has acceptance criteria. - **Red check deferred:** `Repo self-tests` also fails on current `main`, `2e12b312`. The same two files fail on `900c42c7` and on this head: `scripts/tests/build-registry-test.sh` and `scripts/tests/build-scorecards-test.sh`, both from the `REGISTRY.a2ml` drift. Tracked by #1161 §2. Whether to regenerate the registry or retire the check with `.a2ml` is the owner's ruling, so this PR does not regenerate it. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_015bTuGfwCcvjrmNFejydTML Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps the cargo group with 1 update in the /rhodium-standard-repositories/satellites/rsr-certifier directory: rustls.
Updates
rustlsfrom 0.23.37 to 0.23.45Commits
2976d90Prepare 0.23.45f9d4ee9Handshake "alignment" check covers previously-received messagesc4e92e8Keep data needed for HRR processing togethere553a7aserver: TLS1.2 is not available after a HRR5dff9daTest whether server negotiates TLS1.2 after HRR185a063reject a second ClientHello that changes the cipher suite9fafe6dreject a second ClientHello that drops pre_shared_key1b42c5fproviders: zeroize private key DER64ad386Bump version to 0.23.441efbf66bogo: remove PostQuantum setupDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditionsYou can disable automated security fix PRs for this repo from the Security Alerts page.