fix: trust the system CA store so HTTPS works on pyqwest 0.7.0

[qw-in]

A freshly installed SDK cannot complete a single HTTPS request. Every call fails TLS with invalid peer certificate: UnknownIssuer.

pyqwest 0.7.0 added a tls_include_system_certs parameter defaulting to False — a transport built without it trusts no root certificates at all. Before 0.7.0 the parameter did not exist and the system store was always used, so the new default silently removed all trust.

pyqwest 0.6.2: tls_include_system_certs default = PARAM ABSENT  -> OK 200
pyqwest 0.7.0: tls_include_system_certs default = False         -> UnknownIssuer

So we update to pyqwest >= 0.7.0,<0.8.0 and we set tls_include_system_certs=True

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	pyqwest@​0.7.0

View full report

[arcjet-review]

Arcjet Review — 🟡 Medium Risk

Decision: Approved

Rationale: This is a well-scoped, well-tested fix for a real correctness/security bug: pyqwest 0.7.0 flipped tls_include_system_certs to default False, which meant fresh installs of the SDK trusted no root CAs and every HTTPS request failed with UnknownIssuer (masked further by fail-open behavior). The fix (a) sets tls_include_system_certs=True explicitly, (b) centralizes transport construction in a new _transport module so the four previously-independent factories cannot drift again, (c) raises the pyqwest floor to 0.7.0 (necessary because the kwarg is a TypeError on ≤0.6.2), and (d) adds tests that spy on the pyqwest constructors and a guard test that greps the SDK for direct pyqwest.*Transport( construction. The dependency floor change fires the dependency-changes trigger, but it is a minimum-version bump only, targeting a first-party-adjacent Rust HTTP client already in use, and is required to fix the bug. Approving despite Medium risk because the change is small, surgical, tests assert the exact regression, and it improves TLS posture rather than weakening it.

Summary of Changes

Bumps pyqwest minimum to 0.7.0 and passes tls_include_system_certs=True so the SDK trusts the platform CA store, fixing HTTPS failures on fresh installs. Extracts a shared arcjet._transport helper (build_async_transport / build_sync_transport), routes both arcjet._client and arcjet.guard._client factories plus the proxy-env test through it, and adds unit tests that assert the TLS/HTTP2 kwargs and forbid direct pyqwest.*Transport( construction elsewhere in the SDK.

Escalation Triggers

• Dependency Changes: pyproject.toml raises the pyqwest minimum from >=0.3.3 to >=0.7.0.

Notes

Diff is ~200 lines, well under the size threshold. Security-review skill applied: no auth/injection/secrets/crypto concerns; the change strengthens TLS trust (previously effectively disabled by the pyqwest 0.7.0 default flip) and the SDK's fail-open behavior around the original bug is a separate, pre-existing design decision outside the scope of this PR.

Path filtering: 1 file excluded by ignore paths. 6 of 7 files included in review.

_{Review: 99b67e4b | Model: anthropic/claude-opus-4-7 | Powered by Arcjet Review}

[arcjet-review]

Arcjet Review — 🟡 Medium Risk

Decision: Approved

Rationale: Re-review of the same fix previously approved. Diff content is materially unchanged from the prior review — the fix continues to (a) set tls_include_system_certs=True explicitly, (b) centralize transport construction in _transport.py so the four factories cannot drift, (c) raise the pyqwest floor to >=0.7.0,<0.8.0, and (d) add regression tests including a grep guard against direct pyqwest.*Transport( construction. The previous review's inline comments were all explicit nits / non-blocking suggestions; the author has not applied them, which is their prerogative for non-blocking feedback. Not re-raising per the re-review policy. The dependency-changes trigger still fires for the pyproject.toml floor bump, but it's a minimum-version bump to fix a real correctness/TLS-trust bug and adds an upper bound (<0.8.0) which is a small improvement over an unbounded floor. Approving despite Medium risk for the same reasons as before: change is small, surgical, well-tested, and strengthens TLS posture.

Summary of Changes

Re-review of the pyqwest 0.7.0 TLS fix. No material changes since the previous approval; the four transport construction sites still route through arcjet._transport.build_{sync,async}_transport, which sets tls_include_system_certs=True and HTTP/2. Dependency floor pyqwest>=0.7.0,<0.8.0, regression tests include a spy-based check that the flag is passed and a source scan that fails if any SDK module reintroduces a direct pyqwest.*Transport( call.

Escalation Triggers

• Dependency Changes: pyproject.toml bumps pyqwest floor from >=0.3.3 to >=0.7.0,<0.8.0

Notes

Re-review: prior inline nits (test naming, read_text encoding, substring vs regex for the source scan, unused Any import) were non-blocking and remain unaddressed. Respecting the author's implicit decision not to apply them; not re-raising. No new security or correctness concerns. Diff ~200 lines, well under size threshold.

Path filtering: 1 file excluded by ignore paths. 6 of 7 files included in review.

_{Review: d0cbfc4b | Model: anthropic/claude-opus-4-7 | Powered by Arcjet Review}