chore(deps): bump cryptography from 49.0.0 to 50.0.0 in /envs/pi_env

[dependabot]

Bumps cryptography from 49.0.0 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

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.

---

Note

Low Risk
Lockfile-only transitive dependency bump with no direct cryptography usage in pi_env; main review note is major-version behavior changes in crypto/X.509 parsing, not app logic changes.

Overview
Bumps the resolved cryptography package in envs/pi_env from 49.0.0 to 50.0.0 (Dependabot), updating uv.lock only—no application code changes.

50.0.0 includes a security fix for PKCS#7 encryptedKey decryption (CVE-2026-69247), stricter X.509/OCSP parsing, and deprecation of finite-field Diffie-Hellman APIs. cryptography is pulled in transitively (e.g. via Authlib); pi_env does not call it directly.

^{Reviewed by Cursor Bugbot for commit 2ad04e6. Bugbot is set up for automated code reviews on this repo. Configure here.}

[bot-ci-comment]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[cursor]

Alignment Review Report

Two-tier automated review of this Dependabot bump. Net: security-positive and safe on the merits — 0 Tier-1 issues, 1 Tier-2 alignment point (an unreviewed dependency-provenance flip) + 2 non-blocking process/deploy notes. Heads-up: the PR is titled as a single cryptography bump, but the lock was regenerated, so the diff is much larger than the one-line version change.

Automated Checks

• Lint: effectively N/A. .claude/hooks/lint.sh couldn't execute in this review env (no uv), but the PR touches only envs/pi_env/uv.lock (TOML), which ruff/usort don't lint — no lint surface.
• Debug code: CLEAN. check-debug.sh only reports pre-existing print/TODO in src/; this PR changes no .py.

What actually changed (verified: 024eedc9 → 2ad04e69, 1 file, +200/-200)

• cryptography 49.0.0 → 50.0.0 — the only package version change (sdist + 45 wheels from files.pythonhosted.org).
• Index-flip (side effect): all 141 package source entries https://pypi.registries.huggingface.tech/ → https://pypi.org/simple (base 141 mirror / 0 pypi → head 0 mirror / 141 pypi).
• Lockfile revision 2 → 3 (side effect).
• Benign marker re-normalizations from the re-resolve (e.g. { name = "caio", marker = … } → { name = "caio" }); no resolved versions changed and no non-cryptography artifact/hash line changed → the flip is provenance-only.

Security (positive)

• Base 49.0.0 has exactly one outstanding advisory fixed by the target: GHSA-g6cj-pr64-35w5 / CVE-2026-69247 / PYSEC-2026-3552 (fixed_in: 50.0.0, verified on PyPI). 50.0.0 reports vulnerabilities: [].
• Locked sdist sha256:eeac2acb…a6c9 (size 880201) matches PyPI exactly.
• cryptography is transitive-only in pi_env (via authlib); no env code imports it, so the major 49→50 jump has no direct API surface here.

Open RFCs Context

RFCs 000–005 are In Review, 010 is Draft. None concern dependency pinning, lockfiles, or package indexes → no RFC conflict.

Tier 1: Fixes Required

• None.

Tier 2: Alignment Discussion

Principle Conflicts

ALIGNMENT FLAG: Unreviewed dependency-provenance flip (all 141 packages) inside a "bump cryptography" PR

• Principle at stake: Reproducibility — PRINCIPLES.md "Container isolation for reproducibility" (L15) and "Docker overhead is acceptable for reproducibility" (L22)
• The concern: A security bump silently re-sources every package (HF-internal mirror → public PyPI) and bumps the lock revision. This is benign (hashes unchanged) and actually aligns pi_env with the reference env echo_env + ~21 other envs already on pypi.org/simple/revision 3 (public PyPI is the repo majority, and the HF mirror isn't publicly reachable, so it arguably improves external reproducibility). But it wasn't the PR's stated intent and should be a conscious maintainer decision rather than a Dependabot side effect. It also surfaces the broader split (16 envs still pin the HF mirror).
• Suggested reviewers: @Darktex (reproducibility principle author), @burtenshaw (Dependabot config owner)

RFC Conflicts

• None identified.

Non-blocking notes

• exclude-paths bypass (process): .github/dependabot.yml sets exclude-paths: ["envs/**"] for the uv ecosystem (intent: keep Dependabot out of envs/ — @burtenshaw, #566/#644), yet this PR targets envs/pi_env. That's expected for a security update: Dependabot security updates ignore exclude-paths/directory scoping (dependabot-core #14408; see also uv-ecosystem exclude-paths handling #15102). The guard isn't broken — it just can't suppress CVE-driven env bumps. cc @burtenshaw.
• rev-3 / base-image uv deploy heads-up: envs/pi_env/server/Dockerfile builds FROM ghcr.io/huggingface/openenv-base and runs uv sync --frozen, installing uv only if ! command -v uv. If the base image's bundled uv predates ~0.8, uv sync --frozen on a revision 3 lock could fail on a Space/Docker rebuild. Non-blocking (docker-build.yml isn't triggered by uv.lock, and other rev-3 envs deploy fine) — but worth confirming the base image's uv version.

Summary

• 0 mechanical issues to fix
• 1 alignment point for human review (provenance flip) + 2 non-blocking process/deploy notes
• 0 RFC conflicts
• Security-positive; safe to merge on the merits.

  

_{Sent by Cursor Automation: Pre-review}

[cursor]

Security-positive — Tier-1 clean. Base 49.0.0 carries one outstanding advisory that this bump clears: GHSA-g6cj-pr64-35w5 / CVE-2026-69247 / PYSEC-2026-3552 (fixed_in: 50.0.0, verified against the PyPI JSON); 50.0.0 itself reports vulnerabilities: []. This is the only version change in the lock, the sdist sha256:eeac2acb…a6c9 (size 880201) matches PyPI exactly, and all 45 wheels come from files.pythonhosted.org. cryptography is transitive-only in pi_env (via authlib), so the major 49→50 jump has no direct API surface in this env.

[cursor]

ALIGNMENT FLAG (Tier-2): unreviewed provenance flip. This is the first of 141 package source entries flipped from the HF-internal mirror (pypi.registries.huggingface.tech) to public pypi.org/simple — a side effect of the relock, not part of the cryptography bump. It's provenance-only (no artifact/hash changed) and actually aligns pi_env with echo_env + ~21 other envs already on public PyPI, but flipping the source of all 141 packages should be a conscious maintainer decision. Ref reproducibility principle (PRINCIPLES.md L15/L22). cc @Darktex, @burtenshaw.

[cursor]

Side effect + deploy heads-up. The relock also bumped the lockfile revision 2 → 3 (needs uv ≳ 0.8). pi_env/server/Dockerfile builds FROM openenv-base with uv sync --frozen, installing uv only if ! command -v uv — so if the base image's bundled uv predates ~0.8, a Space/Docker rebuild could fail on a rev-3 lock. Non-blocking (docker-build.yml isn't triggered by uv.lock, and other rev-3 envs deploy fine), but worth verifying the base image's uv. Separately, this PR reaching envs/pi_env despite exclude-paths: ["envs/**"] is expected for a security update (Dependabot security updates ignore exclude-paths — dependabot-core #14408). cc @burtenshaw.

[burtenshaw]

Closing in favor of aggregate env Dependabot PR #1015.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.