Raise cryptography upper bound to <50.0.0 (allow 48.x/49.x); unblocks GHSA-537c security fix - #880
Conversation
Sorry, something went wrong.
Signed-off-by: Amitheshkn <amitheshkn@gmail.com>
|
Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application. When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated. If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public. |
Sorry, something went wrong.
|
FWIW I noticed https://github.com/oracle/oci-python-sdk/releases/tag/v2.181.0 included this change (as part of #881). |
Sorry, something went wrong.
|
Closing this PR as it is taken care in https://github.com/oracle/oci-python-sdk/releases/tag/v2.181.0 |
Sorry, something went wrong.
Raise the cryptography upper-bound constraint from <47.0.0 to <50.0.0 in setup.py and requirements.txt .
cryptography 48.0.1 ships the fix for GHSA-537c-gmf6-5ccf (CVE-2026-9076 — a heap out-of-bounds read in the OpenSSL statically linked into cryptography's wheels; OpenSSL advisory 2026-06-09). The current <47.0.0 cap pins downstream applications at cryptography 46.0.7 — the highest version below the fix — so they cannot remediate this HIGH advisory while oci is a dependency. This also affects Python 3.14 free-threaded installs (see #805).
The SDK uses only stable cryptography APIs (RSA signing, key serialization, hashes/HMAC, EC/Ed25519/Ed448, ciphers). Verified in a clean virtualenv: oci==2.180.0 imports and runs on
cryptography==48.0.1 and 49.0.0 :
- oci.core.ComputeClient / oci.core.VirtualNetworkClient import cleanly
- oci.signer.Signer RSA request-signing path works
- oci.signer.load_private_key works
- the pyOpenSSL ↔️ cryptography bridge is intact
pip check reports no issues beyond the (now-raised) cap itself.
Scope
- setup.py : cryptography>=3.2.1,<47.0.0 → <50.0.0
- requirements.txt : same bound on the non-3.9.0/3.9.1 line
- The py3.9.0/3.9.1 pin ( cryptography==42.0.8 ) and pyOpenSSL<27.0.0 are unchanged.
If a smaller increment is preferred, <49.0.0 would still unblock the security fix (cryptography 48.0.1).
Refs: #805