Update the coordinated RustCrypto dependency stack by lthiery · Pull Request #536 · Keats/jsonwebtoken

lthiery · 2026-08-24T18:13:44Z

Updates the RustCrypto family together rather than carrying duplicate hybrid-array/crypto-common/digest/signature generations, as discussed in #502. All versions are now final releases, including rsa 0.10.0.

signature 2 -> 3
hmac 0.12 -> 0.13
sha2 0.10 -> 0.11
p256/p384 0.13 -> 0.14
ed25519-dalek 2 -> 3
rsa 0.9 -> 0.10
rand 0.8 -> 0.10

The code changes are API migrations only: HMAC no longer resets a freshly cloned state, RSA uses BoxedUint and the renamed PrivateKey/PublicKey types with the pkcs1v15 feature enabled, ECDSA uses the updated infallible recoverable-signature API, and the Ed25519 example uses the current RNG API.

This also clears RUSTSEC-2026-0387 (crypto-bigint < 0.7.6, reached through p256/p384 0.13) and RUSTSEC-2023-0071 (Marvin, rsa 0.9). cargo audit is clean.

Validated locally on stable and 1.88: fmt, clippy with -D warnings on both backends, tests on both backends, the wasm-pack jobs, and cargo audit.

Related: #495, #502, #551.

arckoor · 2026-08-24T18:33:06Z

Let's not depend on a rc version

lthiery · 2026-08-24T18:57:30Z

I did take a look at keeping rsa on stable, but the cost is significant.

rsa 0.9 is built against the previous generation of digest/signature/rand traits, so keeping it alongside the updated stack means Cargo.toml carries renamed duplicates (sha2 0.10 + signature 2 + rand_core 0.6 next to their new versions)... so the tree ends up with 14 crates duplicated across two generations (sha2, digest, signature, crypto-common, block-buffer, const-oid, der, spki, pkcs8, pem-rfc7468, rand, rand_core, getrandom, cpufeatures).

The wasm build also gets both getrandom 0.2 and 0.4, each needing its own backend feature in CI. That is the situation #502 recommended avoiding.

rsa has been in its 0.10 pre/rc cycle since early 2024, so IMO, I would go for accepting the rc in favor of getting an unmitigated generational bump.

And then from the security angle, RUSTSEC-2023-0071 (Marvin) is flagged against all rsa versions, but the fix can only ever land on 0.10: it's a breaking change (the bignum backend swap), so 0.9 can't get it. Part of it is already in this rc, and when the advisory is resolved on 0.10, the caret requirement here means downstreams pick it up with a plain cargo update, no release needed on this crate.

Generally, I'd stay way from rc but it seems like a pragmatic step in this case.

arckoor · 2026-08-30T11:04:48Z

@Keats what is your opinion here? I'd preferably wait for rsa v10 and then update everything at once, but this does currently block a few PRs #532 and #535

Keats · 2026-08-30T22:45:22Z

Is it close to a release? I would rather wait

lthiery · 2026-08-31T00:38:48Z

Hard to say but might not be so long now

RustCrypto/RSA#647

timwalls · 2026-10-24T04:08:05Z

RUSTSEC-2026-0387 (crypto-bigint < 0.7.6, constant-time violations, published 2026-10-23) now fails cargo audit/cargo deny for every rust_crypto user: p256/p384 0.13 → elliptic-curve 0.13 → crypto-bigint 0.5, and no 0.5.x fix exists.

ES256/ES384 signing runs secret scalar arithmetic on the affected code, so issuers can't treat it as unreachable.

Since this PR resolves crypto-bigint ≥ 0.7.6, would you reconsider landing it, or a p256/p384-only bump, ahead of rsa 0.10? Downstream we're carrying an audit ignore until then.

…iage Both scanners started failing after 2026-10-23, independently of any dependency change on this branch. The advisories are in the OSV/RustSec database now; the pre-merge lockfile reports them just as the post-merge one does, so the merge did not introduce them. RUSTSEC-2026-0387 crypto-bigint 0.5.5 constant-time timing variability (published 2026-10-23) GHSA-qwgh-2vcv-g2f7 block-buffer 0.10.4 panic corrupts inline buffer position Neither has a reachable fix, and both trace to the same root. crypto-bigint 0.5.5 -- the fix is 0.7.6, which needs elliptic-curve 0.14, which needs ecdsa 0.17, which needs p256/p384 0.14. jsonwebtoken 11.1.0 (the newest release) pins p256 ^0.13.2 and p384 ^0.13.0, so the fix is not reachable from Cargo.toml. The upstream coordinated RustCrypto bump that would move jsonwebtoken to the p256 0.14 / ed25519-dalek 3 generation is Keats/jsonwebtoken#536, which is open and unmerged (checked 2026-10-27). cargo tree -i crypto-bigint --target all crypto-bigint v0.5.5 `-- elliptic-curve v0.13.8 `-- ecdsa v0.16.9 |-- p256 v0.13.2 | `-- jsonwebtoken v11.1.0 | `-- sharecli `-- p384 v0.13.1 `-- jsonwebtoken v11.1.0 sharecli uses that chain only for ES256/ES384 ECDSA public-key decoding and signature verification in local sidecar auth (src/serve_auth.rs). The advisory names secret-dependent branches in arithmetic over secret integers; the secret here is the issuer's private key, which never enters this process, and the operations are verification rather than signing. block-buffer 0.10.4 -- the fix is 0.12.1, already present in the lockfile via tungstenite 0.30.0's digest 0.11, but 0.10.4 is pulled in by the older digest 0.10 generation: cargo tree -i block-buffer@0.10.4 --target all block-buffer v0.10.4 `-- digest v0.10.7 `-- curve25519-dalek v4.1.3 `-- ed25519-dalek v2.2.0 `-- jsonwebtoken v11.1.0 ed25519-dalek 3.x would pull the fixed block-buffer, but it requires jsonwebtoken 12, which does not exist. The path is also not reachable in sharecli: ed25519-dalek is pulled in by jsonwebtoken for EdDSA (Ed25519) JWT algorithm support, and the JWKS loader accepts only RS256/RS384/ RS512 and ES256/ES384 -- src/serve_auth.rs rejects every other `alg` -- so no EdDSA key is ever decoded or verified. The advisory additionally requires a caught panic inside a digest compress callback, which sharecli's code path does not perform. Both entries are time-bounded (ignoreUntil = 2026-11-27 on the osv-scanner side) so they force re-triage when the upstream jsonwebtoken release lands. cargo-deny 0.20.2's ignore schema accepts only id and reason, so the expiry is enforced on the osv-scanner side only; the reason text says so explicitly. cargo-deny reports only RUSTSEC-2026-0387; it does not report GHSA-qwgh-2vcv-g2f7, so that entry exists only in osv-scanner.toml. Both files carry the same 9 advisory ids, and the reasons for all 9 shared ids are byte-identical across the two files. Verified on the merged-with-main state: cargo deny check -> advisories ok, bans ok, licenses ok, sources ok (exit 0) -> 0 advisory errors; 1 warning[advisory-not-detected] for the RUSTSEC-2024-0429 mirror, which is the expected accurate state osv-scanner scan source --lockfile=Cargo.lock --config=osv-scanner.toml -> "No issues found" (exit 0) -> 11 vulnerabilities filtered, 0 unused ignores taplo format --check deny.toml osv-scanner.toml -> clean taplo lint deny.toml osv-scanner.toml -> clean tx-agent: jcode tx-task: PR-976 tx-validated: test tx-scope: ci-config tx-intent: Triage the two advisories published after the last review and add documented, time-bounded ignore entries for the ones with no reachable fix. Signed-off-by: ShareCLI Agent <agent@sharecli.local>

lthiery · 2026-10-27T17:18:29Z

Since RUSTSEC-2026-0387 (2026-10-23) we can see based on the linked activity that there is now a concrete cost to waiting: master pulls crypto-bigint 0.5 through p256/p384 0.13 for ES256/ES384, no fix exists on that line, and every rust_crypto user now fails cargo audit with no upgrade path. This PR resolves crypto-bigint 0.7.9 and clears it.

I'd like to urge you again to consider merging this branch rather than implementing the dual dependency fix which has now been PR'ed.

One idea is to mitigate the upstream rc dependency by using an rc tag here as well? ie: You could merge this and publish 11.2.0-rc.1. Nothing public changes, so it is a minor. Cargo only resolves a pre-release when someone asks for it by name, so jsonwebtoken = "11" users are untouched and audit-blocked users can opt in today. The rsa requirement already matches 0.10.0 final, so going to 11.2.0 later is a version bump with no code change. The one cost is that a stable bugfix before then needs a branch off v11.1.0.

…lock-buffer re-triage) (#976) * chore(deps): unblock OSV + Cargo Deny gates for zbus/zvariant advisory cluster Main is red on two required CI gates after #972 bumped tray-icon 0.25 -> 0.26 and #975 bumped the PhenoShared git source. Both gates fail on the same three RustSec advisories: RUSTSEC-2026-0370 zvariant 5.15.0 RUSTSEC-2026-0371 zbus_names 4.3.4 RUSTSEC-2026-0372 zvariant_derive 5.15.0 All three are 'unmaintained' advisories: the standalone zvariant / zbus_names / zvariant_derive crates were folded into the monolithic zbus 6.x. RustSec reports "No safe upgrade is available!" because zbus 5.x still re-exports the pre-merge crate names for source compatibility. Provenance (cargo tree -i <crate> --target all): sharecli-tray-linux (cfg(target_os = "linux")-gated) -> ksni 0.3.6 -> zbus 5.19.0 -> zvariant / zbus_names / zvariant_derive sharecli does not depend on these crates directly. ksni pulls them in only when the Linux StatusNotifierItem tray crate is built, and that crate is cfg(target_os = "linux")-gated, so the entire ksni dep graph is excluded from compilation on the Windows and macOS targets that gate CI. Config changes (both files must stay in sync - they maintain parallel advisory ignore lists): osv-scanner.toml + 3 ignores for the zbus family (RUSTSEC-2026-0370/0371/0372) + 2 ignores for glib 0.18.x (RUSTSEC-2024-0429 + GHSA-wrw7-89jp-8q8g alias). Dropping the previous gtk-rs block let RUSTSEC-2024-0429 resurface: OSV's lockfile scan does not consider glib 0.18.5 patched, while cargo-deny does. The patched glib 0.20.0 is a breaking release that gtk 0.18.2 (still in the tree) does not accept, so there is no non-breaking upgrade path. - 8 stale gtk-rs 0.18 ignores (RUSTSEC-2024-0412/0413/0415/0416/0418/0419/ 0420/0429). cargo-deny reports each as advisory-not-detected because gtk 0.18.2 / glib 0.18.5 / cairo-rs 0.18.5 are the patched releases of their respective advisories. ~ RUSTSEC-2024-0370 reason corrected: proc-macro-error 1.0.4 is a build-time macro transitive of sharecli-tray-windows via tray-icon's libappindicator backend, not a Linux-only gtk backend dep. cargo-deny treats it as patched; OSV does not. Listed so both scanners agree. deny.toml + 3 ignores for the zbus family + 1 ignore for RUSTSEC-2024-0429 (CI parity with osv-scanner.toml) ~ RUSTSEC-2024-0370 reason corrected to match the actual code path The 7 remaining gtk-rs ignores are retained. cargo-deny emits advisory-not-detected warnings for them (it considers gtk 0.18.2 and friends patched) but those are warnings, not failures, and keeping them means a future tray-icon bump that reintroduces an unpatched gtk-rs is already covered. Verified locally against Cargo.lock at 33fb14a: cargo deny check -> advisories ok, bans ok, licenses ok, sources ok osv-scanner scan -> exit 0, "No issues found", 9 vulnerabilities filtered tx-agent: jcode tx-task: #951 tx-validated: test tx-scope: ci-config tx-intent: Restore green OSV + Cargo Deny required gates on main * fix(ci-config): correct RUSTSEC-2024-0429 advisory rationale and scope CodeRabbit review on #976 correctly flagged that RUSTSEC-2024-0429 was described as an "unmaintained" advisory. The RustSec advisory is informational = "unsound": it covers glib::VariantStrIter's Iterator and DoubleEndedIterator impls, which passed a NULL *mut c_char to a variadic C function as an out-argument. The compiler now discards those writes under optimization, so every impl_get call violates CStr::from_ptr's validity requirement and can crash on a NULL dereference. Affected >=0.15.0 <0.20.0; patched in 0.20.0. The review also showed the previous rationale misstated the dependency scope. Verified against the tree: cargo tree -i glib --target x86_64-pc-windows-msvc -> nothing to print cargo tree -i glib --target aarch64-apple-darwin -> nothing to print cargo tree -i glib --target x86_64-unknown-linux-gnu -> full chain glib is reachable only through sharecli-tray-windows -> tray-icon (feature "libappindicator") -> libappindicator -> gtk -> atk -> glib, and tray-icon 0.26.1 gates its libappindicator dependency behind cfg(any(target_os = "linux", dragonfly, freebsd, netbsd, openbsd)). So the path is Linux-only, not merely "a transitive of sharecli-tray-windows". The Rust sharecli-tray-windows crate is a dev-dependency of the main sharecli crate and is not built by any CI or release workflow: the shipped Windows tray is a C#/MSBuild WinUI app built from windows/ShareCLITray, and release.yml's tray-windows job runs msbuild, never cargo build -p sharecli-tray-windows. The Linux tray releases sharecli-tray-linux, whose ksni path is cfg(target_os = "linux")-gated. Changes (both files keep parallel advisory ignore lists): - RUSTSEC-2024-0429 reason: "unmaintained" -> unsound VariantStrIter impls, with the Linux-only scope and the release-path evidence. - GHSA-wrw7-89jp-8q8g reason: same correction. - RUSTSEC-2024-0370 (proc-macro-error) reason: same Linux-only scope correction. Its advisory class is genuinely "unmaintained", so the class wording is unchanged; only the reachability claim is fixed. - RUSTSEC-2026-0370/0371/0372 reasons unchanged: the RustSec advisories for zvariant / zbus_names / zvariant_derive are confirmed informational = "unmaintained". Verified locally: cargo deny check -> advisories ok, bans ok, licenses ok, sources ok osv-scanner scan -> exit 0, "No issues found", 9 vulnerabilities filtered The remaining cargo-deny "advisory-not-detected" warnings are soft: cargo-deny considers glib 0.18.5 and gtk 0.18.2 patched while OSV's lockfile scan does not. Both files list the advisory so the two scanners agree. tx-agent: jcode tx-task: #976 tx-validated: test tx-scope: ci-config tx-intent: Correct the RUSTSEC-2024-0429 advisory description and dependency scope after review Signed-off-by: Koosha Paridehpour <42529354+KooshaPari@users.noreply.github.com> * fix(ci-config): restore trailing newline in osv-scanner.toml for taplo The `Lint & Format` trunk job runs taplo over the repo's TOML files and reported: ERROR taplo:format_files: the file is not properly formatted path=".../osv-scanner.toml" taplo's only complaint was the missing final newline: the file ended with `"` instead of `"\n`. Verified by diffing taplo's output against the pre-format file — the sole hunk was the `\ No newline at end of file` marker on the RUSTSEC-2024-0449 reason line. The newline was lost in 80ae013, which rewrote the file; main@33fb14af still had it. Confirmed per revision: main: last byte 0a (newline present) 80ae013: last byte 22 (newline missing) c569065: last byte 22 (newline missing) deny.toml was never affected and taplo already accepted it. Verified locally: taplo format --check osv-scanner.toml deny.toml -> exit 0 cargo deny check -> advisories ok, bans ok, licenses ok, sources ok osv-scanner scan -> exit 0, "No issues found", 9 vulnerabilities filtered tx-agent: jcode tx-task: #976 tx-validated: test tx-scope: ci-config tx-intent: Restore the trailing newline taplo requires on osv-scanner.toml Signed-off-by: Koosha Paridehpour <42529354+KooshaPari@users.noreply.github.com> * fix(ci-config): correct glib-sys CI compilation scope in both scanner configs The RUSTSEC-2024-0429 / GHSA-wrw7-89jp-8q8g rationale claimed that `sharecli-tray-windows` "is never built by any CI or release workflow". That was inaccurate: the crate is a dev-dependency of `sharecli` and IS compiled by Linux CI, and it is precisely what pulls glib-sys into the CI build. Verified against the tree at 33fb14a: cargo tree -i glib-sys --target x86_64-unknown-linux-gnu -e normal,dev glib-sys v0.18.1 <- atk-sys <- gtk <- libappindicator <- tray-icon v0.26.1 <- sharecli-tray-windows (dev-dependency of `sharecli`) cargo tree -p sharecli --target x86_64-unknown-linux-gnu -e normal -> 0 glib/gtk nodes (the shipped CLI binary does not link glib) The correct distinction is CI compilation versus shipped artifacts, not "never built by CI". release.yml builds only `--bin sharecli`, `-p sharecli-tray-linux` and `-p sharecli-ffi`; the Windows tray ships as a C#/MSBuild WinUI app. So glib 0.18.5 is compiled during Linux CI test runs and is not linked into any released binary. This is the same edge that makes quality-gate.yml's Unit Tests job fail: that workflow installs no system packages, so glib-sys's build script cannot find `glib-2.0` via pkg-config. ci.yml does install libglib2.0-dev libgtk-3-dev libxdo-dev pkg-config, which is why `ci / lint` and `ci / test` pass. Fixing that workflow is a separate change and is tracked separately. Both files keep identical wording so the two scanners stay in sync. tx-agent: jcode tx-task: #976 tx-validated: test tx-scope: ci-config tx-intent: Correct the glib-sys exposure claim from "never built by CI" to "compiled by Linux CI, absent from shipped artifacts" Signed-off-by: Koosha Paridehpour <42529354+KooshaPari@users.noreply.github.com> * fix(ci-config): reconcile advisory ignore sets and correct zbus rationale The zbus-family ignores described a "Linux-only" transitive path. That was inaccurate: the sharecli feature "desktop-notifications" pulls notify-rust, which declares zbus under cfg(all(unix, not(target_os = "macos"))), so the FreeBSD build (cross-platform.yml runs --all-features) reaches zbus through notify-rust even though sharecli-tray-linux's ksni path is Linux-gated and absent on FreeBSD. Both rationales now describe the two real paths, the per-target reachability difference, and why the advisories still fire: both scanners read only the target-agnostic root Cargo.lock, so neither resolves per-target. The ignore sets were also inconsistent between the two config files. An empirical inventory (osv-scanner and cargo-deny run with the ignore lists removed, plus alias-suppression probes and the OSV API) shows: - RUSTSEC-2024-0412/0413/0415/0416/0418/0419/0420 (gtk-rs) were withdrawn from the OSV database on 2026-08-14, so neither scanner reports them. cargo-deny emitted warning[advisory-not-detected] for all seven. - RUSTSEC-2025-0134 (rustls-pemfile) and RUSTSEC-2025-0140 (gix-date) are active, but neither package is in the root Cargo.lock, so they are dead in both scanners. The 0140 reason also named the wrong crate ("gix = 0.71 pinned in Cargo.toml" names a crate that is not in the tree). - GHSA-wrw7-89jp-8q8g is an alias of RUSTSEC-2024-0429. Either id alone suppresses the whole alias group; listing both makes osv-scanner report the second as an unused ignore. Removed all nine dead entries from deny.toml, removed the seven withdrawn gtk-rs entries and the redundant GHSA alias from osv-scanner.toml, and made the reason strings for the eight shared ids byte-identical across both files. Also corrected two factual errors in the glib rationale. The old comment claimed cargo-deny "considers 0.18.5 patched"; the advisory's [versions] patched range is ">=0.20.0", so 0.18.5 is unpatched. cargo-deny does not report the advisory because it is scoped by [affected.functions] to the glib::VariantStrIter Iterator/DoubleEndedIterator impls and cannot prove they are called - not even under unsound = "all". osv-scanner matches on version range alone and does report it, which is why the osv-scanner.toml entry is load-bearing and the deny.toml mirror is not. Also merged origin/main so the branch carries the RUSTSEC-2026-0381/0382/0383 webpki lockfile fix from #984; without it both scanners fail on the branch's older Cargo.lock. Those advisories have published fixes, so upgrading the lockfile is preferred over ignoring them. Verified on the merge commit (cargo-deny 0.20.2, osv-scanner 2.3.5): - cargo deny check -> advisories ok, bans ok, licenses ok, sources ok (exit 0) - osv-scanner scan source --lockfile=Cargo.lock --config=osv-scanner.toml -> "No issues found" (exit 0), no unused ignores - taplo format --check and taplo lint -> clean on both files tx-agent: jcode tx-task: PR-976 tx-validated: test tx-scope: ci-config tx-intent: Make both scanner ignore sets reflect the advisories that are actually reported, and correct the inaccurate zbus and glib rationales. Signed-off-by: ShareCLI Agent <agent@sharecli.local> * fix(ci-config): ignore the two advisories published since the last triage Both scanners started failing after 2026-10-23, independently of any dependency change on this branch. The advisories are in the OSV/RustSec database now; the pre-merge lockfile reports them just as the post-merge one does, so the merge did not introduce them. RUSTSEC-2026-0387 crypto-bigint 0.5.5 constant-time timing variability (published 2026-10-23) GHSA-qwgh-2vcv-g2f7 block-buffer 0.10.4 panic corrupts inline buffer position Neither has a reachable fix, and both trace to the same root. crypto-bigint 0.5.5 -- the fix is 0.7.6, which needs elliptic-curve 0.14, which needs ecdsa 0.17, which needs p256/p384 0.14. jsonwebtoken 11.1.0 (the newest release) pins p256 ^0.13.2 and p384 ^0.13.0, so the fix is not reachable from Cargo.toml. The upstream coordinated RustCrypto bump that would move jsonwebtoken to the p256 0.14 / ed25519-dalek 3 generation is Keats/jsonwebtoken#536, which is open and unmerged (checked 2026-10-27). cargo tree -i crypto-bigint --target all crypto-bigint v0.5.5 `-- elliptic-curve v0.13.8 `-- ecdsa v0.16.9 |-- p256 v0.13.2 | `-- jsonwebtoken v11.1.0 | `-- sharecli `-- p384 v0.13.1 `-- jsonwebtoken v11.1.0 sharecli uses that chain only for ES256/ES384 ECDSA public-key decoding and signature verification in local sidecar auth (src/serve_auth.rs). The advisory names secret-dependent branches in arithmetic over secret integers; the secret here is the issuer's private key, which never enters this process, and the operations are verification rather than signing. block-buffer 0.10.4 -- the fix is 0.12.1, already present in the lockfile via tungstenite 0.30.0's digest 0.11, but 0.10.4 is pulled in by the older digest 0.10 generation: cargo tree -i block-buffer@0.10.4 --target all block-buffer v0.10.4 `-- digest v0.10.7 `-- curve25519-dalek v4.1.3 `-- ed25519-dalek v2.2.0 `-- jsonwebtoken v11.1.0 ed25519-dalek 3.x would pull the fixed block-buffer, but it requires jsonwebtoken 12, which does not exist. The path is also not reachable in sharecli: ed25519-dalek is pulled in by jsonwebtoken for EdDSA (Ed25519) JWT algorithm support, and the JWKS loader accepts only RS256/RS384/ RS512 and ES256/ES384 -- src/serve_auth.rs rejects every other `alg` -- so no EdDSA key is ever decoded or verified. The advisory additionally requires a caught panic inside a digest compress callback, which sharecli's code path does not perform. Both entries are time-bounded (ignoreUntil = 2026-11-27 on the osv-scanner side) so they force re-triage when the upstream jsonwebtoken release lands. cargo-deny 0.20.2's ignore schema accepts only id and reason, so the expiry is enforced on the osv-scanner side only; the reason text says so explicitly. cargo-deny reports only RUSTSEC-2026-0387; it does not report GHSA-qwgh-2vcv-g2f7, so that entry exists only in osv-scanner.toml. Both files carry the same 9 advisory ids, and the reasons for all 9 shared ids are byte-identical across the two files. Verified on the merged-with-main state: cargo deny check -> advisories ok, bans ok, licenses ok, sources ok (exit 0) -> 0 advisory errors; 1 warning[advisory-not-detected] for the RUSTSEC-2024-0429 mirror, which is the expected accurate state osv-scanner scan source --lockfile=Cargo.lock --config=osv-scanner.toml -> "No issues found" (exit 0) -> 11 vulnerabilities filtered, 0 unused ignores taplo format --check deny.toml osv-scanner.toml -> clean taplo lint deny.toml osv-scanner.toml -> clean tx-agent: jcode tx-task: PR-976 tx-validated: test tx-scope: ci-config tx-intent: Triage the two advisories published after the last review and add documented, time-bounded ignore entries for the ones with no reachable fix. Signed-off-by: ShareCLI Agent <agent@sharecli.local> * fix(ci-config): align the cargo-audit ignore list with the other two scanners .cargo/audit.toml is a third, independent advisory ignore list that CI reads through the `rust-lang/audit-action` in security.yml and through `cargo audit` in audit.yml. It had drifted: it listed only 2 ids while deny.toml and osv-scanner.toml listed 8, so cargo audit reported 7 advisories that the other two scanners were already suppressing. That is why `Dependency Audit` and `SAST Analysis` are red on main and on every PR that does not also change this file. The two jobs are the same cargo-audit run under two workflow entries, so one config fix clears both. cargo audit --file Cargo.lock (before) -> 7 advisories reported, exit 1 RUSTSEC-2024-0370 RUSTSEC-2024-0429 RUSTSEC-2024-0449 RUSTSEC-2026-0370 RUSTSEC-2026-0371 RUSTSEC-2026-0372 RUSTSEC-2026-0387 cargo audit --file Cargo.lock (after) -> no findings, exit 0 All three configs now carry the same 9 advisory ids, and every id is one that a scanner actually reports: RUSTSEC-2023-0071 RUSTSEC-2024-0370 RUSTSEC-2024-0429 RUSTSEC-2024-0436 RUSTSEC-2024-0449 RUSTSEC-2026-0370 RUSTSEC-2026-0371 RUSTSEC-2026-0372 RUSTSEC-2026-0387 The rationale for each is duplicated as a comment here rather than copied into the id list, because cargo-audit's config schema accepts only bare advisory ids -- there is no per-entry expiry, so the 30-day time bounds recorded in deny.toml/osv-scanner.toml cannot be enforced on this side. The header comment says so explicitly instead of implying all three files expire together. cargo-audit's advisory set is the RustSec database, which is a subset of what osv-scanner sees, so this file lists the same ids rather than its own smaller set: RUSTSEC-2024-0436 (paste) and RUSTSEC-2023-0071 (rsa) were already here, and the five that cargo audit newly reports are the same ones deny.toml and osv-scanner.toml already document. Verified: cargo audit --file Cargo.lock -> no findings, exit 0 tx-agent: jcode tx-task: PR-976 tx-validated: test tx-scope: ci-config tx-intent: Bring the cargo-audit ignore list in line with the deny.toml and osv-scanner.toml sets so the Dependency Audit and SAST Analysis gates stop failing on advisories the other scanners already suppress. Signed-off-by: ShareCLI Agent <agent@sharecli.local> * chore(ci): re-trigger review after thread resolution All eight reviewer threads are answered in code. Bot reviewers post a state and do not re-review or self-dismiss, so the reviewDecision stays CHANGES_REQUESTED against a head that already addresses every thread. This empty commit re-runs the gates so they re-evaluate the current head. No file content changes. tx-agent: jcode tx-task: PR-976 tx-validated: test tx-scope: ci-config tx-intent: refresh bot review state on an already-resolved head Signed-off-by: sharecli-bot <sharecli-bot@kooshapari.com> * docs(ci): scope proc-macro-error and glib as Linux/BSD, not Linux-only The rationale text called these paths Linux-only while quoting the gate responsible for them: tray-icon gates libappindicator behind cfg(any(target_os = "linux", dragonfly, freebsd, netbsd, openbsd)), which covers the BSDs as well as Linux. Coderabbit flagged the contradiction. Corrected in all three scanner configs so their reason strings agree: - osv-scanner.toml: comment at the proc-macro-error block + both reasons - deny.toml: comment and RUSTSEC-2024-0370 / RUSTSEC-2024-0429 reasons - .cargo/audit.toml: both comments The zbus-family lines keep "Linux-only" deliberately: that describes the ksni path, sharecli-tray-linux -> ksni -> zbus, gated on cfg(target_os = "linux") and genuinely absent on FreeBSD. The second zbus path via notify-rust is already documented as Linux/BSD. No ignore sets changed, no advisory coverage changed, no production code. cargo audit still exits 0 against this tree. tx-agent: jcode tx-task: PR-976 tx-validated: test tx-scope: ci-config tx-intent: resolve the last coderabbit finding on advisory scope wording Signed-off-by: sharecli-bot <sharecli-bot@kooshapari.com> * docs(ci): re-triage block-buffer 0.10.4 reachability honestly The rationale claimed block-buffer 0.10.4 was "only reached through ed25519-dalek" and therefore unreachable because EdDSA is not accepted. That was wrong, and a reviewer caught it. Measured from Cargo.lock: - Two block-buffer versions coexist: 0.10.4 (vulnerable), 0.12.1 (fixed). - Production SHA-256 sites (src/serve_auth.rs, crates/sharecli-ipc/src/ cache_key.rs, crates/gateway/src/jwt_hs256.rs) all declare sha2 = "0.11", which resolves sha2 0.11.1 -> digest 0.11.3 -> block-buffer 0.12.1, the FIXED version. - Only digest 0.10.7 pulls 0.10.4, and it reaches the build via ecdsa 0.16.9 and rsa 0.9.10 — both on the live JWT verification path (RS256/384/512 and ES256/384 are accepted) — plus curve25519-dalek/ed25519-dalek for EdDSA. The ignore is therefore justified by the panic precondition, not by unreachability: GHSA-qwgh-2vcv-g2f7 needs a CAUGHT PANIC inside a digest compress callback, and sha2's compression does not panic for any input. Comment and reason now say exactly that. Ignore set unchanged; advisory coverage unchanged; time-bounded to 2026-11-27. tx-agent: jcode tx-task: PR-976 tx-validated: test tx-scope: ci-config tx-intent: replace a false reachability claim with the measured dependency graph Signed-off-by: sharecli-bot <sharecli-bot@kooshapari.com> --------- Signed-off-by: Koosha Paridehpour <42529354+KooshaPari@users.noreply.github.com> Signed-off-by: ShareCLI Agent <agent@sharecli.local> Signed-off-by: sharecli-bot <sharecli-bot@kooshapari.com>

akhramov · 2026-11-09T13:01:23Z

https://docs.rs/rsa/0.10.0/rsa/
rsa now has a stable 0.10 release 🙏, so we should not have any more blockers here?

rand 0.10 pulls in getrandom 0.4, which fails to compile on wasm32-unknown-unknown unless its wasm_js feature is enabled. Point the wasm target dependency at getrandom 0.4 and update the CI feature flag from getrandom/js to getrandom/wasm_js.

rsa 0.10.0 gates PKCS#1 v1.5 behind the pkcs1v15 feature, renames RsaPrivateKey/RsaPublicKey to PrivateKey/PublicKey, and folds blinding into pss::SigningKey.

lthiery · 2026-11-09T14:24:05Z

Nice! PR branch updated

arckoor

otherwise lgtm

Alias rsa's PrivateKey/PublicKey back to RsaPrivateKey/RsaPublicKey at the import, and take the JWK modulus and exponent from the PublicKeyParts byte accessors.

rsa's Signer impls draw blinding and PSS salt randomness from the system RNG, so the library no longer needs its own rand dependency. Name rsa's getrandom feature explicitly, since signing now relies on it.

arckoor mentioned this pull request Sep 21, 2026

Add support for ML-DSA signatures #535

Open

This was referenced Oct 24, 2026

chore(deps): ignore RUSTSEC-2026-0387 until jsonwebtoken leaves crypto-bigint 0.5 johncarmack1984/lux#349

Merged

fix(apple-auth): sign one client secret an hour and reuse it johncarmack1984/lux#351

Merged

lifeizhou-ap mentioned this pull request Oct 26, 2026

fix(deps): remove jsonwebtoken to avoid ignoring its cargo-deny advisories aaif-goose/goose#13141

Merged

SDAChess mentioned this pull request Oct 26, 2026

fix(deps): update tokio and crypto-bigint security patches NVIDIA/OpenShell#4924

Merged

11 of 12 tasks

mo-auto mentioned this pull request Oct 26, 2026

fix(jans-cedarling): remove crypto-bigint 0.5 JanssenProject/jans#15497

Closed

5 of 6 tasks

arckoor mentioned this pull request Oct 26, 2026

update dependencies to mitigate RUSTSEC-2026-0387 #549

Closed

babatonga mentioned this pull request Oct 27, 2026

Temporary RustSec exception: RUSTSEC-2026-0387 for crypto-bigint 0.5.5 (expires 2026-12-26) just-tavrn/tavrn-crypto#24

Open

KooshaPari mentioned this pull request Oct 27, 2026

chore(deps): unblock OSV + Cargo Deny gates for zbus/zvariant advisory cluster KooshaPari/ShareCLI#976

Merged

jh247247 mentioned this pull request Oct 28, 2026

Update RustCrypto curves and require patched crypto-bigint #551

Closed

arckoor mentioned this pull request Nov 6, 2026

refactor(rust_crypto): move RSA backend to rsa 0.10.0-rc.17 #502

Closed

lthiery added 3 commits November 9, 2026 14:15

Update RustCrypto dependencies

dc86bcd

Fix wasm build for getrandom 0.4

8e0c2c6

rand 0.10 pulls in getrandom 0.4, which fails to compile on wasm32-unknown-unknown unless its wasm_js feature is enabled. Point the wasm target dependency at getrandom 0.4 and update the CI feature flag from getrandom/js to getrandom/wasm_js.

Use rsa 0.10.0 final

36234be

rsa 0.10.0 gates PKCS#1 v1.5 behind the pkcs1v15 feature, renames RsaPrivateKey/RsaPublicKey to PrivateKey/PublicKey, and folds blinding into pss::SigningKey.

lthiery force-pushed the rustcrypto-2026 branch from b957786 to 36234be Compare November 9, 2026 14:22

gjasny mentioned this pull request Nov 10, 2026

feat: add ES512 support #555

Closed

arckoor requested changes Nov 11, 2026

View reviewed changes

Comment thread src/crypto/rust_crypto/mod.rs Resolved

Comment thread Cargo.toml Resolved

Comment thread src/crypto/rust_crypto/mod.rs Resolved

Comment thread src/crypto/rust_crypto/mod.rs Resolved

Keep the Rsa-prefixed key names and use n_bytes/e_bytes

2de09f9

Alias rsa's PrivateKey/PublicKey back to RsaPrivateKey/RsaPublicKey at the import, and take the JWK modulus and exponent from the PublicKeyParts byte accessors.

pallakatos mentioned this pull request Nov 12, 2026

Remediate crypto-bigint timing advisory Azure/kars#620

Merged

5 of 12 tasks

arckoor reviewed Nov 12, 2026

View reviewed changes

Comment thread src/crypto/rust_crypto/rsa.rs Resolved

Sign RSA with the rsa crate's default RNG

aa20efa

rsa's Signer impls draw blinding and PSS salt randomness from the system RNG, so the library no longer needs its own rand dependency. Name rsa's getrandom feature explicitly, since signing now relies on it.

arckoor approved these changes Nov 12, 2026

View reviewed changes

arckoor merged commit 13f7a06 into Keats:master Nov 13, 2026
10 checks passed

lthiery deleted the rustcrypto-2026 branch November 13, 2026 14:01

Conversation

lthiery commented Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arckoor commented Aug 24, 2026

Uh oh!

lthiery commented Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arckoor commented Aug 30, 2026

Uh oh!

Keats commented Aug 30, 2026

Uh oh!

lthiery commented Aug 31, 2026

Uh oh!

timwalls commented Oct 24, 2026

Uh oh!

lthiery commented Oct 27, 2026

Uh oh!

akhramov commented Nov 9, 2026

Uh oh!

lthiery commented Nov 9, 2026

Uh oh!

arckoor left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

lthiery commented Aug 24, 2026 •

edited

Loading

lthiery commented Aug 24, 2026 •

edited

Loading