-
Notifications
You must be signed in to change notification settings - Fork 52
Bump cryptography from 49.0.0 to 50.0.0 #3228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
dependabot
wants to merge
1
commit into
main
Choose a base branch
from
dependabot/uv/cryptography-50.0.0
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
Oops, something went wrong.
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 38584
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 39843
🌐 Web query:
cryptography 50.0.0 release notes Python 3.9.0 3.9.1 deprecations finite-field DH X.509 OCSP SCT PKCS7 serialization💡 Result:
The cryptography library version 50.0.0, released on July 31, 2026, introduces several significant changes, deprecations, and security updates [1][2]. Deprecations and Security Updates - Diffie-Hellman Key Exchange (FFDH): Finite-field Diffie-Hellman (FFDH) is now deprecated [1][2]. This deprecation encompasses all associated types in cryptography.hazmat.primitives.asymmetric.dh and includes loading FFDH keys or parameters via the key loading APIs [1][2]. Users are advised to migrate to more modern key exchange algorithms [1][2]. - PKCS7 Security Fix: A security issue involving pkcs7_decrypt_der and its PEM/S/MIME variants was addressed [1][2]. These functions no longer expose distinguishable errors or timing when unwrapping a RecipientInfo encryptedKey to prevent potential Bleichenbacher oracle attacks [1][2]. A random key is substituted upon failure, following RFC 3218 [1][2]. X.509, OCSP, and SCT Updates - Stability: X.509 verification APIs are now considered stable and subject to the project's API stability policy [1][2]. - SCT Parsing: Parsing a Signed Certificate Timestamp (SCT) list now rejects encodings that contain trailing bytes after the list or after an individual SCT, rather than silently ignoring them [2][3]. - X.509/ASN.1: Support was added for using x509.Name as a field type in the cryptography.hazmat.asn1 module [2][4]. Additionally, parsing a CRL entry's InvalidityDate extension now strictly rejects GeneralizedTime values that contain fractional seconds or other non-DER forms [2]. Python Support - The cryptography library currently supports Python 3.9+ [2]. Support for older versions, such as Python 3.8, was removed in earlier releases (e.g., v48.0.0) [5]. Other Notable Changes - New features include the addition of xof class methods to SHAKE128 and SHAKE256 for XOFHash usage and the introduction of the Cobblestone recipe for streaming authenticated encryption [1][2]. Additionally, public key and EC private key loading now reject DER encodings where the BIT STRING declares a non-zero number of unused bits [2][4].
Citations:
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 6550
🌐 Web query:
cryptography 50.0.0 changelog release notes supported Python versions deprecations💡 Result:
The cryptography library version 50.0.0 was released on July 31, 2026 [1]. Supported Python Versions Cryptography 50.0.0 supports Python 3.9+ and PyPy3 3.11+ [2]. Key Changes and Deprecations in 50.0.0 - Security Issue: pkcs7_decrypt_der (including PEM and S/MIME variants) was updated to prevent a Bleichenbacher oracle vulnerability. It no longer exposes distinguishable errors or timing when unwrapping an encryptedKey; instead, a random key is substituted on failure [1][2]. - Deprecation: Diffie-Hellman key exchange over finite fields (FFDH) is now deprecated [1][2]. This includes the types in cryptography.hazmat.primitives.asymmetric.dh and loading FFDH keys or parameters via key loading APIs. Users are advised to migrate to modern key exchange algorithms [1][2]. - API Updates: - Added xof class methods to SHAKE128 and SHAKE256 for use with XOFHash [1][2]. - X.509 verification APIs are now considered stable and subject to the project's API stability policy [1][2]. - Introduced the Cobblestone recipe (implementing Cobblestone-128 and Cobblestone-256 for chunked-encryption) [2]. - Behavioral Changes: - Parsing a Signed Certificate Timestamp (SCT) list now strictly rejects encodings containing trailing bytes [2]. - Loading a public or EC private key now rejects DER where the subjectPublicKey/publicKey BIT STRING declares a non-zero number of unused bits [2]. - Parsing an InvalidityDate extension now rejects non-DER forms (such as those with fractional seconds) [2]. - Added support for using x509.Name as a field type in the cryptography.hazmat.asn1 module [2].
Citations:
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 3951
Pin and scope the
cryptographycompatibility check. Replacecryptography>=50.0.0withcryptography==50.0.0and updateuv.lock. The project requires Python>=3.11, so Python 3.9.0 and 3.9.1 are outside its support range. Repository usage is limited to X.509 certificate loading and test certificate generation; no finite-field DH, X.509 verification, OCSP/SCT, PKCS#7, or key-serialization call sites require migration tests.🤖 Prompt for AI Agents
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 219
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 50380
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 18405
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 24867
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 3752
🌐 Web query:
uv documentation whetheruv pip installreads or enforcesuv.lock, and how to install from a uv lockfile in production💡 Result:
The
uv pip installcommand does not read or enforceuv.lock[1][2]. Theuv pipinterface is designed as an alternative topipandpip-toolsand interacts with packages similarly to traditional pip, without awareness of the project-specificuv.lockfile [1][2][3]. To install from a lockfile in production, you should useuv sync[4][5]. ### Installing from a Lockfile in Production For reproducible production environments—such as in CI/CD pipelines or Docker builds—theuv synccommand is the standard and recommended approach [4][6][5]. * Standard Usage: Runninguv syncwill automatically lock (if necessary) and sync the environment to match the dependencies specified inuv.lock[4]. * Production/Docker Usage: To ensure strict adherence to the lockfile during build processes, use:uv sync --frozen --no-install-project[7][5] *--frozen: This flag forcesuvto use the existinguv.lockfile as-is without attempting to update or re-resolve dependencies [7][6]. It will cause the operation to fail if the lockfile is missing or out of sync withpyproject.toml[6]. *--no-install-project: This is often used in Docker builds to install only the dependencies into the environment without installing the current project itself, which is useful for optimizing layer caching [4][7][5]. By usinguv sync --frozen, you guarantee that the exact versions specified in youruv.lockare installed, providing the reproducibility required for production deployments [6][5].Citations:
uv pip install, because it does not honor uv.lock invoke-ai/launcher#131Security Misconfiguration (CWE-494): Download of Code Without Integrity Check
Reachability: External · Exploitability: Moderate
Install production dependencies from
uv.lock.uv.lockrecords hashes forcryptography==50.0.0, and CI runsuv audit --locked. The production container usesuv pip install -e ., which ignoresuv.lockand resolves the open-ended requirements. Replace it withuv sync --frozenor an equivalent hashed installation.🤖 Prompt for AI Agents
Source: Path instructions
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 7524
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 7524
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 50379
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 50379
🏁 Script executed:
Repository: openshift-eng/art-tools
Length of output: 787
Dependency Version Not Pinned (CWE-829): Inclusion of Functionality from Untrusted Control Sphere
Reachability: External · Exploitability: Difficult
Pin the production dependency to an exact version.
uv.lockcurrently resolvescryptographyto50.0.0with hashes, but the project metadata still permits later versions. Usecryptography==50.0.0and updateuv.lock.Suggested change
📝 Committable suggestion
🤖 Prompt for AI Agents
Source: Path instructions