Skip to content

fix(sdk): pick up the emSign CA fixes in the Rust and Python SDK locks - #1467

Open
Leechael wants to merge 1 commit into
nextfrom
security/emsign-sdk
Open

Leechael wants to merge 1 commit into
nextfrom
security/emsign-sdk

Conversation

@Leechael

Copy link
Copy Markdown
Collaborator

The Rust and Python SDK locks still resolve versions that trust certificates issued by the compromised eMudhra/emSign intermediate CAs.

Changes

file package before after
sdk/rust/Cargo.lock rustls-webpki 0.103.15 0.103.16 (RUSTSEC-2026-0383, CVE-2026-111943)
sdk/rust/Cargo.lock webpki-roots 1.0.8 1.0.10
sdk/python/pdm.lock certifi 2025.8.3 2026.10.19
sdk/python/pyproject.toml dependencies (no certifi entry) certifi>=2026.10.19
  • Rust: cargo update -p rustls-webpki --precise 0.103.16 and cargo update -p webpki-roots@1.0.8 --precise 1.0.10. Nothing else in the lock moves. After the change, Cargo.lock has one rustls-webpki entry, and cargo tree -i shows rustls-webpki v0.103.16 and webpki-roots v1.0.10 under reqwest v0.12.28 / hyper-rustls. The SDK uses reqwest rustls-tls, so it trusts the roots compiled in from webpki-roots, plus the rustls-webpki distrust list.
  • Python: pdm lock --update-reuse. Only certifi changes; pdm 2.29.3 also rewrote lock_version from 4.5.0 to 4.5.1 and the content hash. httpx (0.28.1) uses certifi by default. The >= entry makes installs that do not use this lock pick a fixed bundle too.

Self-test against the emSign test site

Rust: a reqwest 0.12 client (rustls-tls, the SDK's features), resolved from a copy of the SDK Cargo.lock:

== next (rustls-webpki 0.103.15, webpki-roots 1.0.8)
TRUSTED (VULNERABLE): https://dv-g3b-emudhra.we-have-a-problem.com/ -> HTTP 200 OK
== this branch (rustls-webpki 0.103.16, webpki-roots 1.0.10)
REJECTED: ... invalid peer certificate: Other(OtherError(CertDistrusted))

Python: httpx.get("https://dv-g3b-emudhra.we-have-a-problem.com/"):

certifi 2025.8.3  (httpx 0.28.1) -> TRUSTED, HTTP 200
certifi 2026.10.19 (this lock)   -> REJECTED: CERTIFICATE_VERIFY_FAILED, unable to get local issuer certificate

Tests run (against the guest-agent simulator built from this branch, the same flow as sdk/run-tests.sh)

  • Rust: cargo test --locked --workspace: all pass. The tappd_client_usage and dstack_client_usage examples run. no_std_test passes. cargo build --locked --all-targets passes.
  • Python: pdm run test: 172 passed. pdm run check (ruff, ruff format, mypy): passes.

Not run here

  • The Go and JS SDK tests: nothing changed there.
  • The sdk-compat workflow.

Notes

  • Both SDKs are libraries. Applications that depend on them resolve their own versions, so their lockfiles need the same bumps (rustls-webpki >= 0.103.16, webpki-roots >= 1.0.10, certifi >= 2026.10.19). Worth a line in the release notes.
  • The Go SDK (go 1.25.0 / go 1.24.0 directives) is a library too. Applications must build with Go 1.26.10 or 1.27.3 to get the crypto/x509 fix. This PR does not change it.
  • The SDKs are not part of any CVM image, so this PR does not change measurements or allowlists.

Rust SDK: reqwest 0.12 with rustls-tls uses the roots compiled in from
webpki-roots. The lock had webpki-roots 1.0.8 and rustls-webpki
0.103.15, and that combination accepts a certificate issued by one of
the compromised eMudhra/emSign intermediate CAs. Move rustls-webpki to
0.103.16 (RUSTSEC-2026-0383, CVE-2026-111943), which rejects chains with
those keys, and webpki-roots to 1.0.10.

Python SDK: httpx uses certifi by default. The lock had certifi
2025.8.3, which still holds emSign ECC Root CA - G3. Move it to
2026.10.19 and add certifi>=2026.10.19 to the dependencies, so
installs outside the lock also get a fixed bundle. pdm 2.29 rewrote
lock_version from 4.5.0 to 4.5.1.

Both SDKs are libraries: applications that depend on them resolve their
own versions, so they need to update their locks too.

Signed-off-by: Leechael Yim <yanleech@gmail.com>
@Leechael
Leechael marked this pull request as ready for review October 22, 2026 02:04

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant