chore(deps): bump cryptography from 46.0.7 to 48.0.1

[dependabot]

Bumps cryptography from 46.0.7 to 48.0.1.

Changelog

Sourced from cryptography's changelog.

48.0.1 - 2026-06-09

* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 4.0.1.
.. _v48-0-0:
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.
</tr></table> 

... (truncated)

Commits

• de987ce 48.0.1 version bump and changelog (#14996)
• 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...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[claude]

LGTM — routine Dependabot bump of cryptography 46.0.7 → 48.0.1 in uv.lock only.

What was reviewed:

• Only uv.lock changed; pyproject.toml is untouched, so no dependency floor was raised (per repo policy).
• cryptography is a transitive dependency here, pulled in solely by pyjwt[crypto] — checked the lock file for other dependents; there are none, and the SDK imports it nowhere directly.
• Checked the 47/48 breaking changes against this usage: Python floor moves to 3.9 (SDK supports 3.10+), and the removals (SECT binary curves, OpenSSL 1.1.x builds) don't affect PyJWT's RSA/EC/HMAC paths.

Extended reasoning...

Overview

This PR is a standard Dependabot dependency bump touching a single file, uv.lock, updating the locked version of cryptography from 46.0.7 to 48.0.1 (new sdist/wheel URLs and hashes). No source code, tests, docs, or pyproject.toml constraints are modified.

Security risks

The change updates a security-relevant library, but in the direction of newer upstream releases from pyca/cryptography via PyPI with pinned hashes generated by Dependabot — the normal, desirable maintenance path. There is no injection, auth, or data-exposure surface introduced by a lock-file resolution change. cryptography reaches this project only transitively through pyjwt[crypto] (verified by grepping uv.lock for dependents), used for JWT signing/verification in the auth code; none of the 47.0.0/48.0.0 backwards-incompatible changes (binary elliptic curve removal, OpenSSL 1.1.x/LibreSSL <4.1 build support removal, ValueError→UnsupportedAlgorithm for unsupported key algorithms, stricter CRL parsing) affect PyJWT's standard RSA/EC/HMAC algorithms.

Level of scrutiny

Lock-file-only Dependabot bumps warrant low scrutiny: the change is mechanical, auto-generated, and fully validated by CI (the test matrix runs 3.10–3.14 across ubuntu/windows with both locked and lowest-direct resolutions, so any real incompatibility would fail the locked runs). The new version's Python requirement (>=3.9) is compatible with the SDK's supported range. The repo's AGENTS.md guidance about not raising dependency floors is respected — no >= constraint changed.

Other factors

The PR timeline contains no reviewer comments or prior reviews, and the multi-agent bug hunting system reported no findings. The bump follows the same established pattern as prior dependency PRs in this repo. I see no design decisions or ambiguity requiring human judgment.