[jslobodzian]

Merge Checklist

• Updated packages build successfully on AMD64 and ARM64.
• Applicable package tests are verified with RUN_CHECK=y.
• Toolchain/worker manifests and toolchain rebuild requirements are resolved where applicable.
• Existing sources and SHA-256 signatures are unchanged and verified.
• Existing security patch stacks are preserved and relevant patches apply with zero fuzz.
• Offline incident-chain rejection and unaffected-anchor retention are checked.
• Ready to merge.

Summary

Address independently bundled trust for the eMudhra intermediate-key compromise.
Updating the system CA package alone does not correct every bundled client store.
The AAA cross-signing path must be covered as well as emSign ECC Root CA - G3.

Target: fasttrack/3.0. Source package: python-virtualenv 20.36.1-7 -> 20.36.1-8.

Change Log

• Remove AAA/ECC G3 from embedded pip 25.0.1 and ECC G3 from pip 25.3 (which already lacks AAA). Run the helper after all existing nested-wheel security backports and renew RECORD hashes and sizes.
• Preserve unrelated certificate bytes, including unaffected emSign G1, C1 and C3 where present.
• Preserve the existing security backports and use a release-only package update.
• Continue to require an updated system trust deployment (ca-certificates-base >= 3.0.0-19);
  this change is not a substitute for that update or a repair of user-supplied CA overrides.

Does this affect the toolchain?

NO: this source package was not found in either architecture toolchain package manifest.

Associated issues / references

• Incident disclosure: https://emudhra.we-have-a-problem.com/
• Anchor identities: https://emudhra.we-have-a-problem.com/roots.json
• Public offline TLS fixtures: https://emudhra.we-have-a-problem.com/chains.zip
• AAA SHA-256: d7a7a0fb5d7e2731d771e9484ebcdef71d5f0c3e0a2948782bc83ee0ea699ef4
• ECC G3 SHA-256: 86a1ecba089c4a8d3bbe2734c612ba341d813e043cf9e8a862cd5c57a36bbe6b

Test Methodology

• Exact Source0 archive verified against the existing signatures.
• Existing and new relevant source patches applied using GNU patch --batch --fuzz=0.
• All fourteen disclosed TLS chains checked against each corrected store:
  28/28 post-change chain/store cases reject for issuer/trust-chain failure.
• Every unrelated certificate remains byte-identical; an unaffected GlobalSign anchor
  continues to validate in each resulting store.
• Source/preparation and offline trust validation only. Native RPM builds,
  RUN_CHECK=y and installed-client validation are pending PR CI/buddy builds.

[Muhammad Falak R Wani (mfrw)]

Check section is not green

[azurelinux-ci-jwt-app]

Auto cherry-pick results:

• 3.0-dev ✅ -> [AUTO-CHERRYPICK] python-virtualenv: remove affected roots from embedded pip wheels - branch 3.0-dev #19725

Auto cherry-pick pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1235578&view=results

[SeanDougherty]

Update: incident-specific exposure addressed by #19708

I am withdrawing the P1 request for cache invalidation as a requirement for this incident. Commit f59907689a01f381c20e92b2461e45e46b1f3968 in #19708 backports CPython's runtime rejection of eight compromised eMudhra intermediate public keys, including cross-signed certificates. This blocks the affected chains even when an old pip CA bundle remains cached.

My earlier installed-RPM reproduction used Python 3.12.15-1 without that guard. I have since verified that all 14 incident fixtures contain a key on the new denylist.

Protection requires deploying the patched CPython runtime, restarting processes to load it, and keeping certificate verification enabled. No cache reset is required for this protection, including in existing environments using that patched runtime. Independent Python installations and other TLS stacks are not automatically covered.

I closed the alternative cache-invalidation drafts #19721 and #19732. The general same-filename cache-consistency issue remains, but is not a blocker for this incident on patched CPython.