Skip to content

fix(deps): allow cryptography 49.x to clear two open CVEs - #315

Merged
cbetta merged 1 commit into
mainfrom
cb/bump-cryptography-49
Sep 15, 2026
Merged

cbetta merged 1 commit into
mainfrom
cb/bump-cryptography-49

Conversation

@cbetta

@cbetta cbetta commented Sep 15, 2026

Copy link
Copy Markdown
Member

What

Widens the cryptography constraint from ^46.0.7 to ^49.0.0, closing two open Dependabot alerts.

CVE Severity Summary
CVE-2026-69249 high Duplicate self-signed intermediates cause exponential certificate path-building
CVE-2026-69248 medium Verifier accepts wildcard DNS names, allowing escape from permittedSubtrees

Vulnerable range is >=42.0.0, <=48.0.0; both are fixed in 49.0.0.

Why it needs doing by hand

The old pin (>=46.0.7,<47.0.0) sat inside the vulnerable range and three majors below the fix, which made the security update unsatisfiable. Dependabot has therefore failed on this dependency on every run since 2026-06-17 — 10 consecutive failures, always pip in /. for cryptography. It will not self-heal until the constraint is widened.

Speakeasy-managed — where the change belongs

The real source of truth is .speakeasy/gen.yaml under python.additionalDependencies.main; the generator writes pyproject.toml from it. Editing only pyproject.toml would be reverted by the next regen.

Both files are updated here: gen.yaml so the change survives regeneration, and pyproject.toml so the fix is effective immediately rather than waiting for the next generation cycle.

Verification

The SDK's entire use of cryptography is two calls in src/gr4vy/auth.pyserialization.load_pem_private_key and hashes.SHA256 — both unchanged across 47→49.

Resolved the runtime set cleanly (cryptography 49.0.0, PyJWT 2.14.0, python-jose 3.5.0; python-jose requires only cryptography>=3.4.0, no upper cap) and exercised the real auth paths against 49.0.0: ES512 key load, JWK thumbprint, jwt.encode and jwt.decode all pass. cryptography 49 requires Python ≥3.9; this SDK requires ≥3.10.

Risk

Low. Neither CVE is reachable from this SDK in practice — both live in X.509 path building and name constraints, which it never invokes. The reason to fix is that the vulnerable version still ships in the dependency tree and will be flagged by merchants' own scanners.

Note cryptography 50.0.1 is already out and also unaffected. I kept to ^49.0.0 as the minimal change that closes both CVEs and matches the existing caret convention — happy to go to 50.x instead if you'd prefer the extra runway.

🤖 Generated with Claude Code

cryptography was pinned to ^46.0.7 (>=46.0.7,<47.0.0), which is inside
the vulnerable range for both of these and three majors below the fix,
so Dependabot could not resolve an upgrade:

- CVE-2026-69249 (high)   duplicate self-signed intermediates cause
                          exponential certificate path-building
- CVE-2026-69248 (medium) verifier accepts wildcard DNS names, allowing
                          escape from permittedSubtrees

Both are fixed in 49.0.0.

Dependabot has failed on this dependency on every run since 2026-06-17
(10 consecutive failures) because the constraint made the security
update unsatisfiable, so this will not self-heal without widening it.

The constraint lives in .speakeasy/gen.yaml under
python.additionalDependencies.main — that is the source of truth the
generator writes pyproject.toml from, so both are updated here to keep
them consistent and to make the fix effective before the next regen.

Verified against 49.0.0: the SDK's whole cryptography surface is
serialization.load_pem_private_key and hashes.SHA256 in src/gr4vy/auth.py,
both unchanged across 47-49. Resolved the runtime set (PyJWT 2.14.0,
python-jose 3.5.0, cryptography 49.0.0) and exercised the ES512
thumbprint, jwt.encode and jwt.decode paths successfully.

Neither CVE is reachable from this SDK in practice — both are in X.509
path building and name constraints, which it never invokes — but the
vulnerable version still ships in the dependency tree and will be
flagged by merchants' scanners.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

🧪 Test coverage

Metric Value
Endpoints reached (HTTP) 119 / 120 (99.2%)

⚠️ 1 endpoint operation(s) have no E2E test. Newly generated endpoints show up here — consider adding tests for them.

  • GET /roles

Endpoint reach is measured from HTTP requests actually sent by the suite (see tests/utils/client.py). See TESTING.md.

@cbetta
cbetta marked this pull request as ready for review September 15, 2026 09:52
@cbetta
cbetta merged commit d0c89b8 into main Sep 15, 2026
13 checks passed
@cbetta
cbetta deleted the cb/bump-cryptography-49 branch September 15, 2026 09:52
cbetta added a commit that referenced this pull request Sep 15, 2026
## What

Moves `cryptography` from `^49.0.0` to `^50.0.1`.

Follow-up to #315, which took `^49.0.0` as the minimal change that
cleared the two open CVEs. 50.0.1 is the current release, so this takes
the extra runway rather than sitting one major behind from the day it
landed.

## No security urgency

49.x is **already outside** the vulnerable range (`>=42.0.0, <=48.0.0`)
for both CVE-2026-69249 and CVE-2026-69248, and the alerts are closed.
50.0.1 carries no known advisories. This is purely about not needing
another bump shortly — merge it whenever suits.

## Speakeasy-managed

Same as #315: the constraint is set in `.speakeasy/gen.yaml` under
`python.additionalDependencies.main`, with the generated
`pyproject.toml` kept in step.

Worth noting as evidence the approach is sound — generation **2.4.11
landed on top of #315 and preserved the `^49.0.0` value**, so `gen.yaml`
is confirmed as the durable place for this.

## Verification

Resolved the runtime set cleanly (`cryptography 50.0.1`, `PyJWT 2.14.0`,
`python-jose 3.5.0`) and exercised the real auth paths from
`src/gr4vy/auth.py` against 50.0.1 — ES512 key load, JWK thumbprint,
`jwt.encode` and `jwt.decode` all pass.

`cryptography` 50 requires Python ≥3.9; this SDK requires ≥3.10. The
SDK's whole surface here is `serialization.load_pem_private_key` and
`hashes.SHA256`, both unchanged across 49→50.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant