nemo-run 0.5.0 depends on cryptography<43.0.0

[cjg-aussee-ai]

I'm not sure, but do we really need this relatively old version of cryptography < 43.0.0?

[hemildesai]

I think this pin was added due to some issue with the newer version a while ago, but I think it should be resolved now. We can try removing the pin and see if everything works as expected.

[benglewis]

I am also stuck with this since we need cryptography>=44.0.1 due to a vulnerability:
GHSA-79v4-65xg-pq4g

[benglewis]

Here's ChatGPT's analysis of why you might want the old cryptography version:

There are several valid reasons why a Python project might constrain its dependency on the cryptography library to < 43.0.0 (i.e., pin to version 42.x or earlier). Below are the major ones — you’ll want to inspect your own environment to determine which one(s) apply.

⸻

1. Runtime environment / OpenSSL compatibility

Version 43.0.0 of cryptography introduced linking changes such that it effectively requires OpenSSL 3.x (or builds statically with it) in many distributions. For example:
• An issue was opened because cryptography==43.0.0 failed with ImportError: libssl.so.3 on a system running OpenSSL 1.1.* (namely Debian 11 “Bullseye”). 
• The installation docs for v43.0.0 state that the wheels are built/tested against OpenSSL 3.0-latest / 3.1-latest / 3.2-latest. 

If your project runs on an OS or container base that has OpenSSL 1.1 (or older) and cannot upgrade easily (for instance legacy Debian or RHEL versions), then pinning <43.0.0 avoids a runtime “missing libssl.so.3” or other linking error.

⸻

2. API / behaviour changes or deprecations

While v43.0.0 may not carry huge documented API breaks (the major breaking changes may be in the OpenSSL linking rather than Python API), upgrading a core dependency like cryptography can still trigger subtle differences (e.g., tightened validation, changed defaults, exceptions instead of warnings). For instance:
• The changelog indicates that in earlier versions support for older OpenSSL and older Python versions was dropped. 
• Upgrades in such libraries sometimes cause downstream libraries (such as pyOpenSSL, SSH libraries, certificate-parsing code) to require newer versions or behave differently.

If your project or pipelines rely on behaviour from older versions of cryptography (including e.g., linking to older OpenSSL, expecting certain exceptions, relying on pickled objects or private APIs), you might pin to a version you’ve validated.

⸻

3. Build / packaging issues

Because cryptography uses Rust components and links OpenSSL, building it from source in certain environments (especially constrained ones like Alpine Linux musl, embedded platforms, manylinux versions) can be a pain. If you use wheels that are known to work in your setup, you may prefer to avoid upgrading until validated. For example: the “manylinux” static wheels depend on specific OpenSSL builds. The installation docs caution about custom OpenSSL builds. 

If your project uses a CI/CD pipeline, container base image, or OS image that was validated against cryptography 42.x and you haven’t yet tested 43.x, you may pin < 43.0.0 to maintain stability.

⸻

4. Immediate vulnerability or bug fixes may require later versions

Interestingly, there are also indications that v43.0.0 had vulnerabilities (or at least issues that required patching). For example the Snyk dashboard flags certain vulnerabilities in the library between versions 42.0.0 and 44.0.1. 

In some cases one might want to pin to ≥ a certain version rather than <43.0.0. But if you’ve evaluated and found that 42.x is acceptable and stable in your setup, you might prefer to avoid the jump to 43.x until upstream libraries you depend on also support it.

⸻

5. Downstream compatibility (other libraries)

If you have code (or libraries you depend on) that explicitly “supports cryptography up to version 42.x” and hasn’t declared compatibility with 43, then it might break (or at least you might lack confidence). Example: one of the release notes for cryptography mentions that for major version bumps the upstream pyOpenSSL needs to bump its max version pin. 

Thus your project may pin <43.0.0 simply to stay within the “so far tested/compatible” combination of dependencies.

⸻
What you should check

To decide whether you can or should upgrade beyond <43.0.0, check:
• What version of OpenSSL your runtime containers/hosts use (openssl version). If <3.0, then likely you have a linking risk.
• Whether your dependencies (particularly ones using cryptography, PyOpenSSL, paramiko, ssh libraries, TLS certificate tooling) declare “supports cryptography 43.x”.
• Whether you have a standard CI/CD build/helm/container image that uses manylinux or static wheels; upgrading cryptography may require rebuilding containers or verifying the build chain (including Rust if you build from source).
• Whether the version you are pinned to has known vulnerabilities — if your organisation has a security policy you may need to upgrade to meet a CVE fix.

And here's the breakdown it product of what changed up to 44.0.1:

Here’s what actually changed in cryptography starting at 43.0.0 up through 44.0.1, focusing on things that can break projects or change behaviour.

⸻

43.0.0 (2024-07-20)

Runtime / dependency changes
• OpenSSL floor raised
• Support for OpenSSL < 1.1.1e is removed. If you build against a system OpenSSL older than that, compilation will fail. 
• LibreSSL floor raised
• Support for LibreSSL < 3.8 is removed. 
• Wheels’ bundled OpenSSL
• Official Windows/macOS/Linux wheels are now built with OpenSSL 3.3.1. 
• Rust requirement increased
• Minimum supported Rust version (MSRV) raised to 1.65.0 (from 1.63.0). 

These are the core reasons a project might need cryptography < 43.0.0 if:
• The build environment only has an older OpenSSL / LibreSSL; or
• A downstream packager builds dynamic wheels against older system OpenSSL.

⸻

API / behaviour changes

These are behaviour-level changes in 43.0.0, i.e. things that can break or subtly change your code even if it compiles.
• RSA key size minimum enforced
• generate_private_key() now enforces a minimum 1024-bit RSA key size. Values below 1024 will raise. (1024 is explicitly called out as insecure, but permitted.) 
• “Decrepit” algorithms moved and deprecated
• New decrepit module introduced for outdated/insecure primitives.
• CAST5, SEED, IDEA, Blowfish moved into this module; they remain in cipher but will be removed from cipher in 45.0.0. 
• TripleDES and ARC4 moved into decrepit and deprecated in cipher; they will be removed from cipher in 48.0.0. 
• If code (or dependent libs) imports these algorithms specifically from cipher and assumes them to be non-deprecated, you’ll start getting deprecation warnings now and breakage later once the removal happens.
• X.509 / PKI behaviour tightening and features
• serialize_certificates() now outputs ASN.1 closer to RFC 2315 recommendations (could affect strict consumers). 
• Added deterministic ECDSA (RFC 6979). 
• Extended X.509 path validation with client certificate verification via ClientVerifier, VerifiedClient, and PolicyBuilder.build_client_verifier(). 
• Added public_key_algorithm_oid properties for Certificate and CSR to expose the PublicKeyAlgorithmOID. 
• Added multiple new *_utc() datetime accessors (timezone-aware equivalents of existing naïve attributes, including e.g. invalidity_date_utc). 
• NameAttribute now raises when attempting to create a Common Name whose length is outside RFC 5280’s permitted range (too short/too long). This can break code that previously accepted “weird” CN lengths and relied on that. 
• New crypto utilities
• rsa_recover_private_exponent() helper. 
• reset_nonce() on cipher contexts for changing the nonce without creating a new context (with restrictions). 
• PKCS7 support
• Added basic PKCS7 encryption / S/MIME via PKCS7EnvelopeBuilder. 

In short, 43.0.0 is a real behaviour change: stricter PKI semantics, enforcement of minimum RSA size, algorithm deprecation, and tighter OpenSSL/LibreSSL/Rust requirements.

⸻

43.0.1 – 43.0.3

These are maintenance/compatibility updates, not feature or API changes:
• 43.0.1 (2024-09-03)
• Wheels updated to use OpenSSL 3.3.2 instead of 3.3.1. 
• 43.0.2 (2024-10-18)
• Fix compilation with LibreSSL 4.0.0. 
• 43.0.3 (2024-10-18)
• Fix release metadata for cryptography-vectors. 

If you can run 43.0.0, you can almost always run 43.0.3; the gating factors are in 43.0.0.

⸻

44.0.0 (2024-11-27)

Runtime / dependency changes
• LibreSSL floor raised again
• Drops support for LibreSSL < 3.9. 
• Python 3.7 deprecated
• Python 3.7 is now deprecated (not yet removed), mirroring upstream Python EOL. 
• Wheels & platform baselines
• Wheels now built with OpenSSL 3.4.0. 
• macOS wheels are built against the macOS 10.13 SDK; users on older macOS versions must either upgrade OS or build from source. 

API / behaviour changes
• Stricter RFC 5280 conformance
• Enforces that extended key usage (EKU) extensions must not be empty, per RFC 5280. Certificates with an empty EKU that previously passed may now be rejected. 
• X.509 verification tweak
• Relaxes Authority Key Identifier requirements for root CAs during X.509 verification to allow fields permitted by RFC 5280 but forbidden by CA/Browser Baseline Requirements. This mainly makes verification more permissive for some root certs. 
• New features
• MultiFernet: support for timestamp extraction. 
• Added support for Argon2id KDF when using OpenSSL 3.2.0+. 
• Added support for the Admissions certificate extension. 
• Added basic PKCS7 decryption (including S/MIME 3.2) via:
• pkcs7_decrypt_der(),
• pkcs7_decrypt_pem(),
• pkcs7_decrypt_smime(). 

The most likely breaking deltas here are: stricter EKU checks and the raised LibreSSL baseline.

⸻

44.0.1 (2025-02-11)

This is primarily a packaging/platform update:
• Wheels now built with OpenSSL 3.4.1. 
• New armv7l manylinux wheels published to PyPI. 
• New manylinux_2_34 wheels published to PyPI. 

No API or behaviour-level changes are listed beyond these build/wheel improvements.

⸻

How this explains cryptography < 43.0.0

A project might explicitly exclude >= 43.0.0 for any of the following concrete reasons:

1. OpenSSL / LibreSSL or distro constraints
   • The build environment uses OpenSSL < 1.1.1e or LibreSSL < 3.8 (and can’t easily be upgraded). 43.0.0+ simply won’t build. 
   • Some distro packages may build cryptography dynamically against system OpenSSL; if the distro hasn’t moved to a new enough OpenSSL but bumped the Python package, they can end up with libssl.so.* issues. That’s not in the upstream changelog, but is a plausible packaging-level cause.
2. Reliance on deprecated or “decrepit” ciphers
   • Code (or dependencies) may still use CAST5, SEED, IDEA, Blowfish, TripleDES, or ARC4 via the old locations and wish to avoid dealing with new warnings, future removals, or the decrepit module split. 
3. Reliance on lax PKI / X.509 behaviour
   • Existing certs or CSR generation may:
   • Use sub-1024-bit RSA keys via generate_private_key() (now forbidden). 
   • Create Common Names whose length violates RFC 5280 (now rejected by NameAttribute). 
   • Later, in 44.0.0, rely on empty EKU extensions (now explicitly rejected). 
4. Conservative dependency policy
   • Some libraries or applications may have been validated only up to 42.x and pinned < 43.0.0 until they’ve explicitly tested the stricter PKI behaviour, new decrepit module, and updated OpenSSL baselines introduced in 43.0.0 and 44.0.x.

If you share a bit about your runtime (distro/OpenSSL/libressl versions, whether you build from source or rely on wheels, and whether you use any of the legacy ciphers), I can narrow this down to the most likely concrete reason your particular project wants < 43.0.0.

[benglewis]

@hemildesai Can I ask if you can look at this and consider my PR? #395 🙏