[Kalyanpulikanti-01]

Unblocks the whole PR lane. supply-chain (cargo-deny) started failing on every PR with nothing in the tree having changed:

error[vulnerability]: Certificate verification may accept distrusted intermediates
  Cargo.lock:344  rustls-webpki 0.103.15        ID: RUSTSEC-2026-0382
error[vulnerability]: Bundled root certificates allow trust in distrusted emSign intermediates
  Cargo.lock:455  webpki-root-certs 1.0.9       ID: RUSTSEC-2026-0383
advisories FAILED, bans ok, licenses ok, sources ok

Both are CVE-2026-111943. The advisories' patched ranges are >= 0.103.16 and >= 1.0.10, and that is exactly what cargo resolves to within semver, so no manifest change is needed.

Why it appeared with no commit behind it

cargo-deny fetches the advisory database on every run. These advisories were published after this repo last ran CI on main (2026-10-19), so main is affected too and simply has not been re-tested — the next push to it would have failed the same way. Nothing regressed; the outside world moved.

This is also why #1924 is red, and not for anything in its own diff: cargo-deny runs at the repository root against the root Cargo.lock, and sdk/python is excluded from that workspace, so the lockfile #1924 adds is not even scanned. #1924 should go green once this lands and it picks up main.

Scope

cargo update -p rustls-webpki -p webpki-root-certs, not a bare cargo update: 5 insertions, 5 deletions, two versions and two checksums, nothing else moved. Transitive patch bumps, no API surface.

Separately, and not in this PR

The nightly sweep (examples) failure is a different and real bug that shipped in v1.12.0: profile.rs truncates an operator label by bytes (label.truncate(38)), and #1614 gave TrieJoin a details string containing ∈ and ∩, so PROFILE on a cyclic pattern nested two levels deep panics on is_char_boundary. profile.rs:324 has the identical bug. Happy to raise that fix next.

[Kalyanpulikanti-01]

This is already on dev and I think this PR is now redundant.

db1e580 ("deps: patch RUSTSEC-2026-0382 and RUSTSEC-2026-0383", landed 2026-10-21 13:11 IST) carries the same three changes this branch proposes:

	dev	this PR
rustls-webpki	0.103.16	0.103.16
webpki-root-certs	1.0.10	1.0.10
tempfile's getrandom	0.3.4	0.3.4

Different commit, identical content — which is why GitHub hasn't auto-closed it the way it did #1904.

This branch is also now well behind dev (the diff against dev shows it removing 40 files' worth of work that has since merged), so updating it would be pure churn for a lockfile bump that is already in.

Recommend closing unmerged. Not closing it myself since it isn't mine to retire — but worth doing soon, because an open PR titled "patch RUSTSEC-…" reads as an unfixed advisory to anyone scanning the list, and the advisory is fixed.

For the record of what the advisories were, since this PR is where someone will look:

• RUSTSEC-2026-0382 — certificate verification may accept distrusted intermediates (rustls-webpki)
• RUSTSEC-2026-0383 — bundled root certificates allow trust in distrusted emSign intermediates (webpki-root-certs)

[Kalyanpulikanti-01]

Retracting my previous comment — it was wrong, and acting on it would have left the advisory on main. Please do not close this PR.

My error: I diffed this branch against dev and concluded it was stale and redundant. Its base is main, not dev. Against its actual base it is a clean 5-line lockfile change, exactly as intended:

$ git diff --stat github/main..c704cbcf
 Cargo.lock | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

The "40 files removed" I reported was me measuring a main-based branch against dev, which of course shows all 55 commits of dev-only work as deletions. Nothing to do with this PR.

main still carries the vulnerable versions:

	main	dev	this PR
rustls-webpki	0.103.15	0.103.16	0.103.16
webpki-root-certs	1.0.9	1.0.10	1.0.10

So dev is patched (by db1e580) and main is not. main is the released branch — v1.12.0 is tagged from it — which means this PR is the only thing in flight that fixes RUSTSEC-2026-0382 and RUSTSEC-2026-0383 on the branch users actually get.

It is MERGEABLE/CLEAN and should go in.

It also unblocks the other two main-targeted PRs. #1934 and #1924 both fail supply-chain (cargo-deny) and cannot be fixed by "Update branch", because updating them merges main — which lacks the patch. GitHub correctly reports them as already up to date with their base; the base itself is the problem. Once this merges, both can update and pass.

Apologies for the noise, and for a comment that recommended closing the fix for a live advisory.