chore(deps): update dependency cryptography to v46 [security]#21
Open
renovate[bot] wants to merge 1 commit intodevelopfrom
Open
chore(deps): update dependency cryptography to v46 [security]#21renovate[bot] wants to merge 1 commit intodevelopfrom
renovate[bot] wants to merge 1 commit intodevelopfrom
Conversation
aba2655 to
cbc57a2
Compare
cbc57a2 to
5f49909
Compare
5f49909 to
5587f1e
Compare
4 tasks
NiklasRosenstein
added a commit
that referenced
this pull request
Mar 15, 2026
## Summary This PR wires up fully-automatic maintenance for the repo so that open security PRs merge themselves and a new PyPI release follows automatically. ### 1. `renovate.json` — automerge for Renovate PRs - **Security updates** (`matchCategories: ["security"]`): automerged immediately with highest priority. This will finally close the 4 long-standing security PRs (#21, #24, #25, #27). - **Minor/patch updates**: automerged after a 3-day stabilisation period (grouped). - `platformAutomerge: true` — uses GitHub's native auto-merge so it respects branch protection rules. - Adds a `dependencies` label to all Renovate PRs for easy filtering. ### 2. `pyproject.toml` — loosen overly tight dependency pins The previous constraints had patch-level upper bounds that directly blocked the open Renovate PRs: | Dep | Before | After | |---|---|---| | `cryptography` | `>=44.0.0,<44.0.1` | `>=44.0.0` | | `urllib3` | `>=2.6.3,<2.6.4` | `>=2.6.3` | `PyJWT<3.0.0` and `requests<3.0.0` are intentional major-version guards and are left as-is. ### 3. `.github/workflows/auto-release.yml` — automatic version tagging After the existing **Python CI** workflow passes on `develop`, this workflow: **Path A — unreleased commits exist (e.g. after Renovate PRs merge):** 1. Auto-bumps the patch version in `pyproject.toml` and `__init__.py` 2. Generates a `.changelog/<new_version>.toml` entry summarising the merged commits 3. Pushes the commit + tag → triggers `release.yml` → publishes to PyPI **Path B — version was manually bumped in a PR:** 1. Checks that a `.changelog/<version>.toml` entry exists 2. If so, tags the version → triggers `release.yml` > **Note:** The auto-release commit is pushed with a `RELEASE_TOKEN` secret (falls back to `GITHUB_TOKEN`). For the tag push to trigger `release.yml`, a PAT stored as `RELEASE_TOKEN` is needed (pushes via `GITHUB_TOKEN` do not trigger further workflows). If you don't have one set up, you can add a fine-grained PAT with `contents: write` scope. ## Test plan - [ ] Merge this PR - [ ] Verify Renovate re-evaluates the open security PRs and enables auto-merge on them - [ ] Confirm that once a security PR merges and CI passes, `auto-release.yml` runs and a new patch tag appears - [ ] Confirm `release.yml` picks up the tag and publishes to PyPI Co-authored-by: Claude Sonnet 4.6 <[email protected]>
5587f1e to
6d19dd4
Compare
6d19dd4 to
2172517
Compare
2172517 to
c64c9c6
Compare
c64c9c6 to
53a2c06
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
44.0.0→46.0.6GitHub Vulnerability Alerts
CVE-2024-12797
pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 42.0.0-44.0.0 are vulnerable to a security issue. More details about the vulnerability itself can be found in https://openssl-library.org/news/secadv/20250211.txt.
If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.
CVE-2026-26007
Vulnerability Summary
The
public_key_from_numbers(orEllipticCurvePublicNumbers.public_key()),EllipticCurvePublicNumbers.public_key(),load_der_public_key()andload_pem_public_key()functions do not verify that the point belongs to the expected prime-order subgroup of the curve.This missing validation allows an attacker to provide a public key point
Pfrom a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret asS = [victim_private_key]Pvia ECDH, this leaks information aboutvictim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup.Only SECT curves are impacted by this.
Credit
This vulnerability was discovered by:
CVE-2026-34073
Summary
In versions of cryptography prior to 46.0.5, DNS name constraints were only validated against SANs within child certificates, and not the "peer name" presented during each validation. Consequently, cryptography would allow a peer named
bar.example.comto validate against a wildcard leaf certificate for*.example.com, even if the leaf's parent certificate (or upwards) contained an excluded subtree constraint forbar.example.com.This behavior resulted from a gap between RFC 5280 (which defines Name Constraint semantics) and RFC 9525 (which defines service identity semantics): put together, neither states definitively whether Name Constraints should be applied to peer names. To close this gap, cryptography now conservatively rejects any validation where the peer name would be rejected by a name constraint if it were a SAN instead.
In practice, exploitation of this bypass requires an uncommon X.509 topology, one that the Web PKI avoids because it exhibits these kinds of problems. Consequently, we consider this a medium-to-low impact severity.
See CVE-2025-61727 for a similar bypass in Go's
crypto/x509.Remediation
Users should upgrade to 46.0.6 or newer.
Attribution
Reporter: @1seal
Release Notes
pyca/cryptography (cryptography)
v46.0.6Compare Source
v46.0.5Compare Source
v46.0.4Compare Source
v46.0.3Compare Source
v46.0.2Compare Source
v46.0.1Compare Source
v46.0.0Compare Source
v45.0.7Compare Source
v45.0.6Compare Source
v45.0.5Compare Source
v45.0.4Compare Source
v45.0.3Compare Source
v45.0.2Compare Source
v45.0.1Compare Source
v45.0.0Compare Source
v44.0.3Compare Source
v44.0.2Compare Source
v44.0.1Compare Source
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.