Repository navigation
Stop trusting the compromised eMudhra CA certificates - #697
Merged
Merged
Conversation
Eight eMudhra (emSign) intermediate CA certificates have private keys that can be recovered from the public certificates. Software that trusts the root "emSign ECC Root CA - G3" accepts certificates issued with them. uv.lock pinned certifi 2025.8.3, which includes that root, and hf-xet 1.1.9, whose compiled-in CA list also includes it. Upgrade only those two packages: certifi 2026.10.19 removes the root, and hf-xet 1.7.0 verifies against the operating-system CA store. The certification workflow installs this lock with `uv sync --frozen`. Every workflow pinned uv 0.12.14, whose compiled-in CA list includes the root. Pin uv 0.13.4, which removes it, and regenerate the lock with that uv, as docs/release-bundles.md requires when the uv pin changes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2 tasks
Co-Authored-By: Claude Opus 5.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
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.
Fixes #698
Incident
On 2026-10-20 it was disclosed that eight eMudhra (emSign) intermediate CA certificates have private keys below 256, so anyone can recover them from the public certificates and issue a certificate for any domain. The TLS intermediates chain to the root "emSign ECC Root CA - G3" and were also cross-signed under Sectigo's "AAA Certificate Services". Browsers and current operating systems already reject them; software that carries its own CA list is still exposed until that list is updated. Details: https://emudhra.we-have-a-problem.com
What in this repository trusted the affected roots
uv.lockcertify-uk-release.yamlinstalls the lock withuv sync --frozen --extra uk --extra devin theprepareandqualifyjobs (scheduled every two hours), which sendHUGGING_FACE_TOKENto Hugging Face. The docs targets in theMakefile(uv run) and localuv syncalso install from the lock.https://dv-g3b-emudhra.we-have-a-problem.com/returned HTTP 200. With certifi 2026.10.19 it failed withCERTIFICATE_VERIFY_FAILED.uv.lock(dependency of huggingface-hub 0.34.4)rustls-platform-verifier, which reads the operating-system CA store.setup-uvstep of every workflowuv pip install --index-url https://dv-g3b-emudhra.we-have-a-problem.com/simple/ ...with uv 0.12.14 completed the TLS handshake and failed only on the response's content type. With uv 0.13.4 it failed withinvalid peer certificate: UnknownIssuer.Not changed, and why:
requests>=2.31.0) are unchanged, and users resolve their own certifi.uv pip installsteps in every workflow do not readuv.lock; they resolve from PyPI and already get certifi 2026.10.19 and hf-xet 1.7.0.pypa/gh-action-pypi-publish@release/v1already pins certifi 2026.10.19 (Upgrade certifi and sigstore pypa/gh-action-pypi-publish#427, merged 2026-10-20).push.yamlsets up Node.js 18.x, which has no fixed release, butmake docsruns onlyquarto renderand nothing in the repository runs Node.js. Left as it is.Changes
uv.lock:uv lock --upgrade-package certifi --upgrade-package hf-xetwith uv 0.13.4. certifi 2025.8.3 → 2026.10.19, hf-xet 1.1.9 → 1.7.0, and the lock'srevision3 → 5 (written by uv 0.13.4). No other package changed..github/workflows/{push,pr_code_changes,pr_docs_changes}.yamlandUV_VERSIONincertify-uk-release.yaml: uv 0.12.14 → 0.13.4.docs/release-bundles.mdrequires the uv pin and the lock to change together in one reviewed PR, because the lock's marker spelling depends on the uv version.changelog.d/698.fixed.md: changelog fragment.Checks
uv lock --lockedwith uv 0.13.4: passes. uv 0.12.14 also reads the new lock (uv lock --lockedpasses), so local installs with the older uv still work.python scripts/release_lock.pywith uv 0.13.4 onPATH(the reviewed-lock check run byBundleVerification,VersioningandPublish): passes.python scripts/release_lock.py --refreshwith uv 0.13.4 changed only the root package's version inuv.lock, as the release requires.pytest tests/test_release_lock.pywith uv 0.13.4 onPATH: 25 passed.uv sync --frozen --extra uk --extra dev --python 3.13 --dry-runwith uv 0.13.4: plans certifi 2026.10.19 and hf-xet 1.7.0.model.safetensorsfromhf-internal-testing/tiny-random-gpt2through Xet storage.https://pypi.org/andhttps://huggingface.co/.towncrier check,ruff format --check .,ruff check .: pass. All workflow files parse as YAML.After merge
main,push.yamlpublishes a patch release (6.10.1) and dispatches version-bump PRs to consumer repositories. The wheel's contents differ only in the version and the bundle metadata that records it.uv syncto install certifi 2026.10.19 and hf-xet 1.7.0.mainonly to a candidate built on the currentmain, so such a candidate is rebuilt from the new lock.Environment-variable verification
This PR changes CI workflows, so I checked every environment variable the changed code reads or declares:
UV_VERSION(changed value only): declared as a literal in the workflow-levelenv:block ofcertify-uk-release.yaml. Every job inherits it, and thesetup-uvsteps of theresolve,prepare,qualify,replay,catch-up,acceptandpromotejobs read it through${{ env.UV_VERSION }}, as before. Verified.version:input ofsetup-uv, not environment variables.setup-uvdownloads uv using itsgithub-tokeninput, which defaults to the automaticgithub.token; unchanged.env:binding or job permission changed. The steps that install from the lock still receiveHUGGING_FACE_TOKENfrom the GitHub Actions secret, unchanged.The repository's PR guidance asks for a tracking issue and a
Fixes #first line. This PR came from an organization-wide check for the eMudhra certificates, and no issue was opened for it; add one if you want it tracked.🤖 Generated with Claude Code