[jdoss]

Part 1 of #40's plan, plus the renewal-unit bug it found.

infisical: talk to Infisical through its SDK

• The client: PSI's own httpx client for Infisical is gone. InfisicalClient keeps its interface, where each call takes a token from PSI's token file cache, and infisicalsdk 1.0.17 makes the requests, retries them and raises their errors.
  • Calls the SDK lacks go through its request layer (InfisicalSDKClient.api): batch create, certificates, and GCP and Azure login. So every Infisical call shares one session.
  • That session gets what the SDK leaves unset: a 30 s timeout on every request, and the CA bundle. The bundle is ca_cert, which was documented but never used until now; else SSL_CERT_FILE, which the container units set but requests ignores; else requests' default.
• Errors: they become InfisicalAPIError, a ProviderError with the HTTP status (None when Infisical couldn't be reached). Lookup, setup's retries and the importer read that status instead of httpx's exceptions; setup still retries an unreachable instance and 404/502/503.
• Logins:
  • Universal auth and AWS IAM use the SDK's own logins.
  • The SDK signs AWS logins for the region's STS endpoint, so an AWS identity in Infisical must name that endpoint. The docs now say so; no current deployment uses aws-iam.
  • GCP and Azure fetch their metadata token with httpx. A failing metadata service is now a ProviderError rather than an uncaught error.
• SDK bug worked around: with no AWS credentials, the SDK raises botocore's NoCredentialsError with a message that class doesn't accept, so the caller gets a TypeError. PSI checks for credentials before the SDK's login, as its old code did.
• Dependencies: infisicalsdk and requests are added. boto3 stays, for that credential check.
• Tests: the client, login, setup-retry and importer tests run the real SDK against a stand-in Infisical (tests/fake_infisical.py), answering where the adapter hands a request to the network. That includes psi infisical env as qvm's CI runner runs it: exports, quoting, and a refused login.

unitgen: run psi infisical tls renew from the renewal units

• The renewal service and Quadlet ran psi tls renew, which doesn't exist, so scheduled renewals always failed.
• A test now runs each unit's command line through psi's own CLI with --help. It fails on the old string.

deps: move PyKCS11 to 1.5.20, which builds on Python 3.14

• Why every PSI build was failing: PyKCS11 ships only as source, and 1.5.18's wrapper calls PyInt_FromLong, which Python 3.14 doesn't declare. Building it fails with bookworm's SWIG 4.1.0 and trixie's SWIG 4.3.0 alike.
• Why it only showed up now: CI got by on build layers cached in May. Once that cache expired, every build failed in the builder's uv sync, docs-only Plan Infisical through its SDK, then each cloud's secret store #40 included.
• The fix: 1.5.20 builds on the builder's CPython 3.14.2, and the production image imports PyKCS11.

ruff check, ruff format --check and ty check are clean; 397 tests pass, locally and inside the test image. Once this is released, qvm's runner can move its PSI image pin to the new image after psi infisical env has fetched its pipeline folder from the real instance.