fix(security): update ewf to 0.4.10 to clear RUSTSEC-2026-0253 - #13
Merged
Conversation
`lru 0.12.5` reached this repo transitively through `ewf 0.4.7`, which declares
`lru ^0.12`. ewf 0.4.9 onward declares `^0.18.1`, so taking 0.4.10 drops the
vulnerable copy: the graph now resolves a single `lru 0.18.2`.
RUSTSEC-2026-0253 is an unsoundness in `LruCache::pop()` — a panicking key
`Drop` skips `detach()`, leaving dangling pointers that a later eviction writes
through (CWE-416/415, reachable from safe Rust).
Lockfile only. The declared requirement `ewf = { version = "0.4", optional =
true }` already admitted 0.4.10, so nothing in the manifest moves — the lock was
simply pinned to a release that predates the fix.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
cargo vet --locked verifies [[trusted]] entries against publisher records cached in imports.lock, and neither new version was recorded: ewf:0.4.10 missing ["safe-to-deploy"] safe-read:0.2.2 missing ["safe-to-deploy"] Both are first-party with existing trust entries (h4x0r, user-id 347968; ewf from 2026-03-05, safe-read from 2026-07-15). No trust entry is added here — only the publisher records they verify against. safe-read is NEW to this graph rather than a version bump: ewf 0.4.10 replaced its lru usage with safe-read, which is the same change that clears RUSTSEC-2026-0253. Normally a new crate entering the graph is a supply-chain decision rather than bookkeeping; here the decision predates the PR by a month and the crate is our own, so the standing trust covers it. Co-Authored-By: Claude Opus 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.
fix(security): update ewf to 0.4.10 to clear RUSTSEC-2026-0253
lru 0.12.5reached this repo transitively throughewf 0.4.7, which declareslru ^0.12. ewf 0.4.9 onward declares^0.18.1, so taking 0.4.10 drops thevulnerable copy: the graph now resolves a single
lru 0.18.2.RUSTSEC-2026-0253 is an unsoundness in
LruCache::pop()— a panicking keyDropskipsdetach(), leaving dangling pointers that a later eviction writesthrough (CWE-416/415, reachable from safe Rust).
Lockfile only. The declared requirement
ewf = { version = "0.4", optional = true }already admitted 0.4.10, so nothing in the manifest moves — the lock wassimply pinned to a release that predates the fix.