Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 15 Packages Wiki Activity Actions

sec: move crypto-bigint off a release yanked after it was picked, and record why warnings are not gated #565

Merged
dcharlot merged 1 commit from sec/crypto-bigint-unyanked into main 2026-11-01 13:32:10 -05:00
Conversation 0 Commits 1 Files changed 2 +30 -10
dcharlot commented 2026-11-01 09:43:27 -05:00
Owner
Copy link

Two small things, both follow-ups to my own work in #449.

The fix I shipped landed on a yanked release

#449 bumped crypto-bigint 0.7.3 → 0.7.6 in smart-byte to clear RUSTSEC-2026-0387 (secret-dependent branches in operations meant to be constant-time). Since then the author has yanked every 0.7.x below 0.7.9 — 0.7.1 through 0.7.8 inclusive, 0.7.6 among them. So the version chosen to fix an advisory is now a withdrawn release.

Moved to 0.7.10, which is not yanked and still satisfies the advisory's >=0.7.6. No yanked dependency remains anywhere in the tree.

This is the case for re-reading the yanked list after advisory work rather than once: the pin was correct when it was made, and went stale for a reason outside the tree.

An omission in the gate, turned into a decision

check-advisories.py says warnings are not gated because they are "advice about maintenance, not a reachable defect". That is honest for unmaintained and evasive for the other two, so the header now says what is actually true:

  • unsound-with-a-fix is a real defect a bump would close — one was a use-after-free in LruCache::pop(). It is not gated today only because every current instance is either pinned by a dependent (zstd-safe under wasmtime 49's module cache, which nothing here configures) or needs a semver-major move of a transitive crate (lru, rand, glib). A gate that is red for things nobody can act on teaches people to bypass it, which costs more than it catches. The trigger to gate it is those becoming movable.
  • yanked can happen to a version that was correct when chosen, as above. Gating it would turn every PR red for a decision made outside the tree, so it stays a warning — but it is a standing review item, which is how this one was caught.

Both are now recorded decisions with trigger conditions, not an unexamined gap.

Checked

60 lockfiles, the same 19 allowances, self-test green on all six cases, lockfile check current, smart-byte builds.

While here I also verified the four zstd allowances added since #486 (not mine): their load-bearing claim is that sandbox-exec-wasm never configures wasmtime's module cache. It holds — the engine is built from Config::new() plus consume_fuel(true), and there is no cache_config_load anywhere in sandbox-rs.

🤖 Generated with Claude Code

Two small things, both follow-ups to my own work in #449. ### The fix I shipped landed on a yanked release #449 bumped `crypto-bigint` 0.7.3 → **0.7.6** in smart-byte to clear RUSTSEC-2026-0387 (secret-dependent branches in operations meant to be constant-time). Since then the author has yanked **every 0.7.x below 0.7.9** — 0.7.1 through 0.7.8 inclusive, 0.7.6 among them. So the version chosen to fix an advisory is now a withdrawn release. Moved to **0.7.10**, which is not yanked and still satisfies the advisory's `>=0.7.6`. No yanked dependency remains anywhere in the tree. This is the case for re-reading the yanked list after advisory work rather than once: the pin was correct when it was made, and went stale for a reason outside the tree. ### An omission in the gate, turned into a decision `check-advisories.py` says warnings are not gated because they are "advice about maintenance, not a reachable defect". That is honest for `unmaintained` and evasive for the other two, so the header now says what is actually true: - **unsound-with-a-fix** is a real defect a bump would close — one was a use-after-free in `LruCache::pop()`. It is not gated *today* only because every current instance is either pinned by a dependent (`zstd-safe` under wasmtime 49's module cache, which nothing here configures) or needs a semver-major move of a transitive crate (`lru`, `rand`, `glib`). A gate that is red for things nobody can act on teaches people to bypass it, which costs more than it catches. The trigger to gate it is those becoming movable. - **yanked** can happen to a version that was correct when chosen, as above. Gating it would turn every PR red for a decision made outside the tree, so it stays a warning — but it is a standing review item, which is how this one was caught. Both are now recorded decisions with trigger conditions, not an unexamined gap. ### Checked 60 lockfiles, the same 19 allowances, self-test green on all six cases, lockfile check current, smart-byte builds. While here I also verified the four zstd allowances added since #486 (not mine): their load-bearing claim is that `sandbox-exec-wasm` never configures wasmtime's module cache. It holds — the engine is built from `Config::new()` plus `consume_fuel(true)`, and there is no `cache_config_load` anywhere in sandbox-rs. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
sec: move crypto-bigint off a release that was yanked after I picked it, and say plainly why warnings are not gated
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 2m30s
Details
standards workspaces build + test / macOS energy backends (pull_request) Has been skipped
Details
standards workspaces build + test / smart-byte-rs (smart-byte/smart-byte-rs, smart-byte-rs, linux) (pull_request) Successful in 3m35s
Details
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 22m1s
Details
8fc1d07940 
Two follow-ups to my own work in #449.

**The fix shipped on a yanked release.** #449 bumped crypto-bigint 0.7.3 ->
0.7.6 in smart-byte to clear RUSTSEC-2026-0387 (secret-dependent branches in
operations meant to be constant-time). The author has since yanked every 0.7.x
below 0.7.9 — 0.7.1 through 0.7.8, 0.7.6 among them — so the version chosen to
fix an advisory is now withdrawn. Moved to 0.7.10, which is not yanked and
still satisfies the advisory's `>=0.7.6`. No yanked dependency remains anywhere
in the tree.

The pin was correct when it was made and went stale for a reason outside the
tree, which is the argument for re-reading the yanked list after advisory work
rather than once.

**An omission in the gate, turned into a decision.** The header said warnings
are not gated because they are "advice about maintenance, not a reachable
defect". That is honest for `unmaintained` and evasive for the other two, both
of which have been worth acting on. It now says what is true:

  - unsound-with-a-fix is a real defect a bump would close; one was a
    use-after-free in `LruCache::pop()`. It is not gated *today* only because
    every current instance is either pinned by a dependent (zstd-safe under
    wasmtime 49's module cache, which nothing here configures) or needs a
    semver-major move of a transitive crate (lru, rand, glib). A gate that is
    red for things nobody can act on teaches people to bypass it, which costs
    more than it catches. The trigger to gate it is those becoming movable.
  - yanked can happen to a version that was correct when chosen, as above.
    Gating it would turn every PR red for a decision made outside the tree, so
    it stays a warning — but it is a standing review item, which is how this
    one was caught.

Recorded decisions with trigger conditions, rather than an unexamined gap.

60 lockfiles, the same 19 allowances, self-test green on all six cases,
lockfile check current, smart-byte checks clean.

Co-Authored-By: Claude Opus 5 <[email protected]>
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Transaction-Science/open-standards!565
No description provided.