Bump cryptography from 45.0.7 to 48.0.0

[dependabot]

Bumps cryptography from 45.0.7 to 48.0.0.

Changelog

Sourced from cryptography's changelog.

48.0.0 - 2026-05-04

* **BACKWARDS INCOMPATIBLE:** Support for Python 3.8 has been removed.
  ``cryptography`` now requires Python 3.9 or later.
* **BACKWARDS INCOMPATIBLE:** Loading an X.509 CRL whose inner
  ``TBSCertList.signature`` algorithm does not match the outer
  ``signatureAlgorithm`` now raises ``ValueError``. Previously, such CRLs
  were parsed successfully and only rejected during signature validation.
* Added support for :doc:`/hazmat/primitives/asymmetric/mlkem` and
  :doc:`/hazmat/primitives/asymmetric/mldsa` when using OpenSSL 3.5.0 or
  later, in addition to the existing AWS-LC and BoringSSL support. This means
  post-quantum algorithms are now available to users of our wheels.

Note: Going forward, we do not guarantee that all functionality

in cryptography will be available when building against

OpenSSL. See :doc:/statements/state-of-openssl for more information.

.. _v47-0-0:
47.0.0 - 2026-04-24

• Support for Python 3.8 is deprecated and will be removed in the next cryptography release.
• BACKWARDS INCOMPATIBLE: Support for binary elliptic curves (SECT* classes) has been removed. These curves are rarely used and have additional security considerations that make them undesirable.
• BACKWARDS INCOMPATIBLE: Support for OpenSSL 1.1.x has been removed. OpenSSL 3.0.0 or later is now required. LibreSSL, BoringSSL, and AWS-LC continue to be supported.
• BACKWARDS INCOMPATIBLE: Dropped support for LibreSSL < 4.1.
• BACKWARDS INCOMPATIBLE: Loading keys with unsupported algorithms or keys with unsupported explicit curve encodings now raises :class:~cryptography.exceptions.UnsupportedAlgorithm instead of ValueError. This change affects :func:~cryptography.hazmat.primitives.serialization.load_pem_private_key, :func:~cryptography.hazmat.primitives.serialization.load_der_private_key, :func:~cryptography.hazmat.primitives.serialization.load_pem_public_key, :func:~cryptography.hazmat.primitives.serialization.load_der_public_key, and :meth:~cryptography.x509.Certificate.public_key when called on certificates with unsupported public key algorithms.
• BACKWARDS INCOMPATIBLE: When parsing elliptic curve private keys, we now reject keys that incorrectly encode a private key of the wrong length because such keys are impossible to process in a constant-time manner. We do not believe keys with this problem are in wide use, however we may revert this change based on the feedback we receive.
• Deprecated passing 64-bit (8-byte) and 128-bit (16-byte) keys to :class:~cryptography.hazmat.decrepit.ciphers.algorithms.TripleDES. In a

... (truncated)

Commits

• 8e03e30 bump for 48.0.0 release (#14796)
• 295e0d2 Add AGENTS.md with CLAUDE.md symlink (#14794)
• 104a2de Bump BoringSSL, OpenSSL, AWS-LC in CI (#14793)
• 67ec1e5 call check_length early on AesSiv::encrypt (#14792)
• b2da57a changelog for mldsa/mlkem for openssl (#14791)
• 3cf44ad ML-KEM OpenSSL support (#14781)
• 2e31639 ML-DSA OpenSSL support (#14773)
• 5affe5a fix rust nightly clippy (#14790)
• 2e73ca4 bump rust-openssl dep and update EcPoint::mul_generator to mul_generator2 (#1...
• 82ebd3b Bump BoringSSL, OpenSSL, AWS-LC in CI (#14785)
• Additional commits viewable in compare view

[rtibblesbot]

Dependency Update Review

Package: cryptography 45.0.7 → 48.0.0
Semver risk: Multi-major (3 major versions)
Dependency type: Production
CI status: Failing — build failures on macOS and Windows (cffi conflict; see inline comment)

Changelog Analysis

Sources consulted:

• PR body (truncated; 46.x and earlier not shown)

Breaking changes (47.0.0–48.0.0):

• Python 3.8 support removed — project uses Python 3.10, unaffected
• Binary elliptic curves (SECT*) removed — no usage in project source
• OpenSSL 1.1.x support removed — wheels bundle OpenSSL 3.x
• LibreSSL < 4.1 dropped
• Key loading now raises UnsupportedAlgorithm instead of ValueError for unsupported algorithms — no direct usage found in project source
• New peer dependency requirement: cffi>=2.0.0 (up from cffi>=1.12)

Changelog for the 46.x range is truncated in the PR body; no breaking changes found in the visible 47.0.0–48.0.0 entries that affect this project, aside from the cffi requirement.

Compatibility Assessment

• Direct cryptography API usage in project source: none (from cryptography / import cryptography not found)
• Peer dependency conflict: yes — cffi>=2.0.0 required; setup.py pins cffi==1.14.4
• Python version: 3.10 (satisfies the new 3.9+ minimum)
• Code changes required: yes — cffi pin in setup.py must be updated alongside this bump

Recommendation

REQUEST_CHANGES — breaking build on both platforms due to cffi version conflict. Once cffi is bumped to a >=2.0.0-compatible pin the remaining changelog changes are low-risk for this project.

---

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

How was this generated?

Reviewed the pull request diff checking for:

• Correctness: bugs, edge cases, undocumented behavior, resource leaks, hardcoded values
• Design: unnecessary complexity, naming, readability, comment accuracy, redundant state
• Architecture: duplicated concerns, minimal interfaces, composition over inheritance
• Testing: behavior-based assertions, mocks only at hard boundaries, accurate coverage
• Completeness: missing dependencies, unupdated usages, i18n, accessibility, security
• Principles: DRY (same reason to change), SRP, Rule of Three (no premature abstraction)
• Checked CI status and linked issue acceptance criteria
• For UI changes: inspected screenshots for layout, visual completeness, and consistency

[rtibblesbot]

blocking: Both macOS and Windows CI builds fail with a dependency conflict introduced by this bump:

ERROR: Cannot install kolibri-app and kolibri-app==0.5.1 because these package versions have conflicting dependencies.
    kolibri-app 0.5.1 depends on cffi==1.14.4
    cryptography 48.0.0 depends on cffi>=2.0.0; platform_python_implementation != "PyPy"

cryptography 48.0.0 raised its cffi minimum from >=1.12 to >=2.0.0, which is incompatible with the cffi==1.14.4 pin on line 36. This PR needs a companion bump: update cffi==1.14.4 to a version satisfying cffi>=2.0.0. The two changes should land together.

[rtibblesbot]

praise: Exact-version pinning (==) for cryptography is the right call for a bundled desktop app — it makes builds fully reproducible and prevents unexpected wheel changes on rebuilds, which matters for a security-critical dependency.

[rtibblesbot]

Prior findings

Unaddressed (re-raised below):

• cffi conflict (blocking) — no reply, cffi==1.14.4 pin unchanged; CI still fails with the same dependency conflict

0/1 prior findings resolved. 1 re-raised below.

---

CI failing on all three checks (Build EXE, Build DMG, uv-lock lint) — all caused by the same cffi conflict.

• blocking: cffi conflict, re-raised on pyproject.toml:14 (see inline comment)

---

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

How was this generated?

Compared the current PR state against findings from a prior review:

• Retrieved prior bot reviews deterministically via the GitHub API
• Classified each prior finding as RESOLVED, UNADDRESSED, ACKNOWLEDGED, or CONTESTED
• Only raised NEW findings for newly introduced code
• Reviewed the pull request diff checking for correctness, design, architecture, testing, completeness, and adherence to DRY/SRP principles
• Checked CI status and linked issue acceptance criteria

[rtibblesbot]

blocking: The cffi conflict from round 1 is still present. cryptography==48.0.0 requires cffi>=2.0.0, but line 15 pins cffi==1.14.4. All three CI checks fail with this error:

Because cryptography==48.0.0 depends on cffi>=2.0.0 and your project depends on cffi==1.14.4,
we can conclude that cryptography==48.0.0 and your project are incompatible.

This PR needs a companion bump: update cffi==1.14.4 on line 15 to cffi>=2.0.0 (or a specific compatible version such as cffi==2.0.0). Both changes should land together.

[dependabot]

Superseded by #262.