chore: bump cryptography to ~=49.0

[gjtorikian]

Summary

• Move the cryptography requirement from ~=48.0 to ~=49.0 (i.e. >=49.0,<50.0).
• Re-lock uv.lock: cryptography 48.0.1 → 49.0.0.
• The SDK only uses long-stable cryptography APIs (Fernet, and Cipher/algorithms/modes + default_backend in session.py / vault/_resource.py), which are unchanged in the 49.x line.

Test plan

• uv sync --locked --dev resolves cleanly against the new range
• uv run pytest passes

[greptile-apps]

Greptile Summary

This PR updates the cryptography dependency and lockfile. The main changes are:

• Moves the runtime dependency from the 48.x series to the 49.x series.
• Regenerates uv.lock with cryptography 49.0.0.
• Updates lockfile package metadata to match the new dependency specifier.

Confidence Score: 4/5

Not safe to merge until the dependency specifier matches the intended compatibility range.

The changed package metadata has a clear resolver-visible compatibility regression for consumers constrained to the 48.x cryptography line.

pyproject.toml

T-Rex Logs

What T-Rex did

• T-Rex reproduced a dependency-resolution failure when pinning cryptography to 48.x while workos 8.3.0 requires cryptography~=49.0, and attempted uv-based resolution and wheel metadata checks but those tools were unavailable.
• T-Rex ran the uv-workflow before and after transcripts to verify cryptography can be upgraded from 48.0.1 to 49.0.0 without breaking the test suite; the before and after transcripts show the same test count with updated cryptography and similar runtimes.
• T-Rex compared cryptography 48.0.1 and 49.0.0 for a cryptography-backed SDK and confirmed Fernet/session-cookie/AES-GCM roundtrips succeed in both versions; no findings were filed because head matched the base behavior.

_{Ran code and verified through T-Rex}

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
pyproject.toml:11
**Dependency range narrowed**
The new `cryptography~=49.0` requirement resolves to `>=49.0,<50.0`, so packages pinned to the current 48.x line can no longer install this SDK even though the PR says the goal is to allow `>=48`. This changes the published package contract in the opposite direction from the requested lower-bound widening and will force downstream consumers off 48.x immediately.

```suggestion
  "cryptography>=48",
```

_{Reviews (2): Last reviewed commit: "chore: bump cryptography to ~=49.0" | Re-trigger Greptile}

[greptile-apps]

T-Rex pricing update — T-Rex was free through June 2026. Effective July 1, 2026, T-Rex adds 2 credits on top of the standard 1-credit review (3 total). T-Rex settings

[greptile-apps]

Upper bound omitted
cryptography>=48 does not encode the intended <50 ceiling, so the published package metadata will accept cryptography 50+ immediately. This contradicts the PR summary's >=48,<50 compatibility window and removes the human-review gate for the next major from downstream resolution.

Artifacts

Repro: focused metadata and specifier evaluation script

• Contains supporting evidence from the run (text/x-python; charset=utf-8).

Repro: script output showing cryptography 50.0.0 is permitted

• Keeps the command output available without making the summary code-heavy.

_{Ran code and verified through T-Rex}

Prompt To Fix With AI

This is a comment left during a code review.
Path: pyproject.toml
Line: 11

Comment:
**Upper bound omitted**
`cryptography>=48` does not encode the intended `<50` ceiling, so the published package metadata will accept `cryptography` 50+ immediately. This contradicts the PR summary's `>=48,<50` compatibility window and removes the human-review gate for the next major from downstream resolution.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Dependency range narrowed
The new cryptography~=49.0 requirement resolves to >=49.0,<50.0, so packages pinned to the current 48.x line can no longer install this SDK even though the PR says the goal is to allow >=48. This changes the published package contract in the opposite direction from the requested lower-bound widening and will force downstream consumers off 48.x immediately.

Suggested change

	"cryptography~=49.0",
	"cryptography>=48",

Artifacts

Repro: pip resolver script for a temporary consumer pinned to cryptography 48.x

• Contains supporting evidence from the run (text/x-shellscript; charset=utf-8).

Repro: verbose pip output showing ResolutionImpossible for cryptography==48.0.0 versus workos cryptography~=49.0

• Keeps the command output available without making the summary code-heavy.

Repro: uv resolver script attempted for a temporary consumer pinned to cryptography 48.x

• Contains supporting evidence from the run (text/x-shellscript; charset=utf-8).

Repro: uv resolver attempt output showing uv was unavailable

• Keeps the command output available without making the summary code-heavy.

Repro: wheel metadata extraction attempt output showing build tooling was unavailable

• Keeps the command output available without making the summary code-heavy.

_{Ran code and verified through T-Rex}

Prompt To Fix With AI

This is a comment left during a code review.
Path: pyproject.toml
Line: 11

Comment:
**Dependency range narrowed**
The new `cryptography~=49.0` requirement resolves to `>=49.0,<50.0`, so packages pinned to the current 48.x line can no longer install this SDK even though the PR says the goal is to allow `>=48`. This changes the published package contract in the opposite direction from the requested lower-bound widening and will force downstream consumers off 48.x immediately.

```suggestion
  "cryptography>=48",
```

How can I resolve this? If you propose a fix, please make it concise.