Bump cryptography from 46.0.5 to 50.0.0

[dependabot]

Bumps cryptography from 46.0.5 to 50.0.0.

Changelog

Sourced from cryptography's changelog.

50.0.0 - 2026-07-31

* **SECURITY ISSUE**:
  :func:`~cryptography.hazmat.primitives.serialization.pkcs7.pkcs7_decrypt_der`
  and its PEM and S/MIME variants no longer expose distinguishable errors or
  timing when unwrapping a ``RecipientInfo``'s ``encryptedKey``, which could
  act as a Bleichenbacher oracle for callers that decrypt untrusted messages.
  A random key is now substituted on failure, as described in :rfc:`3218`.
  Credit to **@X1AOxiang** for reporting the issue. **CVE-2026-69247**
* Deprecated Diffie-Hellman key exchange over finite fields (FFDH).
  Everything FFDH is deprecated, including the types in
  ``cryptography.hazmat.primitives.asymmetric.dh`` and loading FFDH keys or
  parameters with the key loading APIs. Users should migrate to a more
  modern key exchange algorithm.
* Added ``xof()`` class methods to
  :class:`~cryptography.hazmat.primitives.hashes.SHAKE128` and
  :class:`~cryptography.hazmat.primitives.hashes.SHAKE256` for constructing
  algorithm instances configured for use with
  :class:`~cryptography.hazmat.primitives.hashes.XOFHash`.
* The :mod:`X.509 verification <cryptography.x509.verification>` APIs are now
  considered stable and are subject to our API stability policy.
* Added the :doc:`/cobblestone` recipe, an implementation of the
  Cobblestone-128 and Cobblestone-256 instantiations of the `C2SP
  chunked-encryption specification
  <https://c2sp.org/chunked-encryption>`_ for streaming authenticated
  encryption of large messages.
* Parsing a Signed Certificate Timestamp list now rejects encodings that
  carry trailing bytes after the list or after an individual SCT, instead of
  silently ignoring them.
* Added support for using :class:`~cryptography.x509.Name` as a field type in
  the :doc:`/hazmat/asn1/index` module.
* Loading a public key or an EC private key now rejects DER where the
  ``subjectPublicKey`` (or EC ``publicKey``) ``BIT STRING`` declares a non-zero
  number of unused bits, instead of silently ignoring it.
* Parsing a CRL entry's ``InvalidityDate`` extension now rejects a
  ``GeneralizedTime`` that carries fractional seconds or another non-DER form,
  matching the strict encoding already required for every other X.509 time
  field.
* :func:`~cryptography.x509.ocsp.load_der_ocsp_request` and
  :func:`~cryptography.x509.ocsp.load_der_ocsp_response` now reject a request
  or response whose ``version`` field is not ``v1``, the only version defined
  by RFC 6960, matching the version validation already performed when loading
  certificates, CSRs and CRLs.
* :class:`~cryptography.hazmat.primitives.hashes.XOFHash` is now supported
  when building against AWS-LC.
* HMAC (and therefore PBKDF2-HMAC) with SHA-3 hashes is now supported when
  building against AWS-LC.
* Diffie-Hellman (:doc:`/hazmat/primitives/asymmetric/dh`) is now supported
  when building against AWS-LC.
</tr></table> 

... (truncated)

Commits

• dcb7050 Prepare for 50.0.0 release (#15372)
• 53fccd9 Don't leak how PKCS#7 encryptedKey decryption failed (#15369)
• d472f97 Add from __future__ import annotations to all src/ Python files (#15371)
• 908773d Bump downstream dependencies in CI (#15368)
• 2cc07cc Bump BoringSSL, OpenSSL, AWS-LC in CI (#15367)
• c94ede9 chore(deps): bump ruff from 0.16.0 to 0.16.1 (#15366)
• 67a8308 chore(deps): bump virtualenv from 21.7.0 to 21.7.1 (#15365)
• 95018ff Release the GIL in one-shot AEAD encrypt/decrypt (#15361)
• 6954733 Release the GIL during DH and DSA parameter generation (#15364)
• 6893b94 Import _serialization instead of serialization in x509/extensions (#15363)
• Additional commits viewable in compare view

[rtibblesbot]

🔵 Review posted

Last updated: 2026-08-08 05:46 UTC

[rtibblesbot]

PR #730 — cryptography 46.0.5 → 50.0.0 (claimed), multi-major, transitive production dependency via the google_drive extra. CI passing (15/15). Requesting changes because the lockfile does not do what the title says.

What the lockfile actually does: cryptography is removed entirely (grep -c cryptography uv.lock → 0), google-auth is downgraded 2.49.1 → 2.47.0, and rsa 4.9.1 is re-added. No cryptography entry exists at any version after this change.

 [[package]]
 name = "google-auth"
-version = "2.49.1"
+version = "2.47.0"
 dependencies = [
-    { name = "cryptography" },
     { name = "pyasn1-modules" },
+    { name = "rsa" },
 ]

Root cause: cryptography 50.0.0 was published 2026-07-31, inside the repo's rolling exclude-newer = "7 days" cooldown (pyproject.toml:86). Dependabot doesn't apply that cooldown when picking a target, so uv couldn't select 50.0.0 and instead found a resolution where cryptography isn't required at all — reachable only by walking google-auth back to 2.47.0, the last release where cryptography is an extra rather than a hard requirement (2.49.1 lists cryptography>=38.0.3 unconditionally; 2.47.0 lists rsa<5,>=3.1.4 + cryptography>=38.0.3; extra == "cryptography").

Regression this hides: google-auth 2.48.0 added cryptography as a required dependency and 2.49.0 removed the deprecated rsa dependency. Reverting to 2.47.0 puts RSA signature verification for Google service-account credentials back on pure-Python rsa, and drops the 2.48/2.49 fixes (NO_GCE_CHECK handling, configurable GCE metadata retries, mTLS IAM domain support, circular-import fix). google-auth ships to users via the google_drive extra (pyproject.toml:50) and is exercised by the Google Drive transfer handler — production surface, not dev-only.

CI green is not evidence here. CI does install the extra (.github/workflows/pythontest.yml:127), so it confirms google-auth 2.47.0 + rsa still work. It says nothing about whether dropping cryptography was correct: nothing in the suite requires cryptography to be installed. The only reference is tests/pipeline/test_transfer.py:74-92, a generate_test_private_key() helper that is never called and swallows the ImportError.

Security context: the 50.0.0 fix is CVE-2026-69247, a Bleichenbacher oracle in pkcs7_decrypt_der and its PEM/S-MIME variants. Neither ricecooker nor google-auth's credential code decrypts untrusted PKCS#7, so there's no reachable exposure and no urgency to force-land 50.0.0.

Suggested resolution: close this PR and either re-run dependabot after 2026-08-07 when 50.0.0 clears the cooldown, or land the natural upgrade deliberately. On main, uv lock --upgrade-package cryptography resolves cleanly, keeps google-auth at 2.49.1, introduces no rsa, and splits by marker:

{ name = "cryptography", version = "47.0.0", marker = "python_full_version <= '3.9'" },
{ name = "cryptography", version = "49.0.0", marker = "python_full_version > '3.9'" },

If taking that path, note two BACKWARDS INCOMPATIBLE entries in 49.0.0 — x86_64 macOS support removed, 32-bit Windows support removed. CI runners are unaffected (macos-latest is arm64, windows-latest is x64); the exposure is Intel-Mac chef authors installing ricecooker[google_drive] on Python ≥ 3.10, who would need to build from source. No API-level breaking change in 47.0.0–50.0.0 touches this project — there are no direct cryptography imports outside the dead test helper.

Separately worth checking: .github/dependabot.yml:11 sets cooldown.default-days: 7 for the uv ecosystem, matching exclude-newer, yet this PR was opened for a 4-day-old release. If dependabot's cooldown isn't honoured for uv, this failure mode recurs on every fast-moving transitive dependency — and each recurrence looks like a normal green bump.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

Ran a dependency-update review pipeline over the version bump:

• Classified the bump by semver (patch / minor / major) and dependency type (production vs. development)
• Extracted the changelog and release notes across the version range
• Assessed compatibility with this project's usage and whether any code changes are required
• Treated CI as the primary safety net
• Scaled the review depth to the update's risk
• Chose the verdict from semver risk, changelog findings, and CI status

[rtibbles]

@dependabot recreate

[rtibblesbot]

PR #730 — cryptography 46.0.5 → 50.0.0 (major, 4 majors; transitive production dep via google-auth). CI green (19/19). 1 of 2 prior findings resolved; 1 still open.

Changelog across 47–50: no API change touches this project (no direct cryptography imports outside the dead generate_test_private_key() helper in tests/pipeline/test_transfer.py). Two BACKWARDS INCOMPATIBLE entries in 49.0.0 — x86_64 macOS and 32-bit Windows support dropped — don't affect CI runners (macos-latest is arm64, windows-latest is x64). Security: 50.0.0 is the CVE fix this bump exists for.

[blocking] uv.lock:537 — the cryptography==50.0.0 pin downgrades google-auth and re-adds rsa on Python ≤ 3.9

The lockfile forks google-auth: 2.47.0 for python_full_version <= '3.9', 2.49.1 above. cryptography appears once at 50.0.0 (uv.lock:340), referenced only by the 2.49.1 branch (uv.lock:563). 2.47.0 is the last release where cryptography is an extra rather than a hard requirement, so the 3.9 fork gets no cryptography at all and pulls in rsa 4.9.1 (uv.lock:2342), a package main does not have — pure-Python RSA verification for Google service-account credentials, and no CVE fix.

This is now avoidable. 50.0.0 published 2026-07-31T14:23Z; the repo's exclude-newer = "7 days" cooldown cleared it 2026-08-07T14:23Z. Running the natural upgrade on main (uv 0.12.3, same cooldown):

$ uv lock --upgrade-package cryptography
Resolved 151 packages in 2.01s
Updated cryptography v46.0.5 -> v47.0.0, v50.0.0

Diffed against this PR's lockfile, the only differences are: rsa 4.9.1 and google-auth 2.47.0 present only here, cryptography 47.0.0 present only in the natural resolve. That keeps google-auth at 2.49.1 everywhere, adds no rsa, and covers the ≤ 3.9 fork with 47.0.0. Dependabot can't reach it because it pins cryptography==50.0.0 across the whole resolution and so can't pick a lower version inside the 3.9 fork.

Suggested resolution: close this PR and land uv lock --upgrade-package cryptography from main. Same 50.0.0 above 3.9, no google-auth regression, no new rsa.

CI passing on all three Python 3.9 jobs confirms 2.47.0 + rsa still work, not that dropping cryptography on 3.9 is correct — nothing in the suite requires it to be importable.

Prior-finding status

RESOLVED — uv.lock — cryptography removed from the lockfile entirely at every version
UNADDRESSED — uv.lock:537 — google-auth downgraded 2.49.1 → 2.47.0 and rsa 4.9.1 re-added; now scoped to Python ≤ 3.9, and now avoidable since 50.0.0 cleared the exclude-newer cooldown
UNADDRESSED — .github/dependabot.yml:11 — cooldown.default-days: 7 appears not to be honoured for the uv ecosystem; out of scope for this branch diff, but the failure mode recurs on every fast-moving transitive dependency

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

Ran a dependency-update review pipeline over the version bump:

• Classified the bump by semver (patch / minor / major) and dependency type (production vs. development)
• Extracted the changelog and release notes across the version range
• Assessed compatibility with this project's usage and whether any code changes are required
• Treated CI as the primary safety net
• Scaled the review depth to the update's risk
• Chose the verdict from semver risk, changelog findings, and CI status