Repository navigation
Automation: Update uv.lock - #2996
Merged
Merged
Conversation
cryptography 50.0.0 added MLKEM768PublicKey and MLKEM1024PublicKey to the return type of Certificate.public_key(). ML-KEM is a key encapsulation mechanism, so those keys have no verify(), and _verify_signature reached its generic branch and raised AttributeError instead of reporting a result. Such a key cannot have produced a signature, so verification now fails closed and returns 0 rather than treating the signature as valid. The hand-maintained CertificateIssuerPublicKeyTypes union gains the same two types, which is what mypy was reporting: the union had drifted narrower than public_key(). cryptography exports no public alias to track instead, so the union is spelled out and carries a comment saying what it must follow. This is the same drift PYTHON-5915 fixed for ML-DSA.
Member
|
@sleepyStick I manually ran the uv lock workflow because the cryptography 50.0 typing failures were showing up in my otel branches. I pushed a fix for PYTHON-6032 directly to this branch. |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
sleepyStick
approved these changes
Aug 17, 2026
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.
Updated packages
1.3.0,1.6.0→1.3.0,1.7.01.42.97,1.43.57→1.42.97,1.43.721.42.97,1.43.57→1.42.97,1.43.722.0.0,2.1.0→2.0.0,2.1.13.4.9→3.5.147.0.0,49.0.0→47.0.0,50.0.026.7.0→26.7.0,26.8.03.2.5,3.5.4→3.2.5,3.5.50.10.0,1.1.0→1.1.00.13.0→0.15.026.2→26.326.0.1,26.1.2→26.0.1,26.2.12.20.0→2.21.026.2.0,26.3.0→26.2.0,26.4.082.0.1,83.0.0→82.0.1,84.0.02.8.4,2.9.1→2.8.4,2.9.20.49.3,1.3.1→0.49.3,1.6.00.39.0,0.51.0→0.39.0,0.52.315.0.1,16.1.1→15.0.1,16.1.1,17.0.1PYTHON-6032: OCSP fix required by the cryptography bump
PYTHON-6032 rides along here because it has to land with the bump:
cryptography50.0.0 breaks without it, and it has nothing to prove without the new lock.cryptography50.0.0 added ML-KEM keys to whatCertificate.public_key()returns. ML-KEM is a key encapsulation mechanism with noverify(), so OCSP signature verification raisedAttributeErrorinstead of returning a result. It now fails closed, since such a key cannot have produced a signature and reporting it valid would be wrong.The fix also widens the hand-maintained public-key union, which had drifted narrower than
public_key(). That drift is what thestaticandTyping Testsjobs were reporting on every branch resolvingcryptography50.Verified with the lock file in this PR:
mypypasses, as it does againstcryptography47.0.0, the declared minimum.test_ocsp_support.pygoes from 57 to 59 passing, the delta being regression tests for both ML-KEM key sizes.