JesseMarkowitzandClaude Opus 5
c1a73b3d77
Phase 0B ran the upstream application on a network with no route out and the first turn died in tiktoken, which downloads its BPE table the first time anything counts a token. The browser separately fetched three font families from Google on every page load. Neither is visible on a machine that has been online once, which is why both now have tests. The tokenizer table is vendored at backend/app/context/vendor/cl100k_base.tiktoken and backend/app/context/encoding.py builds the encoding from it directly, verifying its SHA-256 against the digest tiktoken itself pins for that URL. No code path in the tokenizer can reach the network any more — not a warm cache, not an environment variable a deployment could forget. The encoding was checked token for token against tiktoken's own. The three font families are self-hosted as variable fonts under frontend/public/fonts/ (343 KiB, Latin and Latin Extended), declared in frontend/src/styles/fonts.css, and re-vendored by frontend/tools/vendor_fonts.py. Their OFL licences ship beside them. With no remote asset left, the CSP drops both Google hosts and gains object-src, base-uri and form-action; woff2 also gets its real media type, which Python's table lacks on a slim image. A trusted-LAN Ollama turned out not to work at all over HTTPS. httpx verifies against the certifi bundle, so an endpoint whose certificate comes from a CA the user installed on their own machines — a StartOS server's Ollama, for one — was refused with CERTIFICATE_VERIFY_FAILED while curl and the browser on the same host accepted it. app/tlstrust.py builds one context that unions the platform CA store with certifi's, and all four outbound clients use it. A union rather than a swap, so an image with an empty system store cannot start failing on endpoints that worked before. Verification itself is untouched: CERT_REQUIRED, hostname checking on, and no insecure escape hatch. The storyteller listener is now loopback by explicit statement rather than by inheriting uvicorn's default: start.sh, start.ps1, and docker-compose.yml, which publishes to 127.0.0.1 rather than every interface. Reaching an Ollama on another machine is outbound and needs none of that inbound exposure. backend/requirements.lock pins the exact tested closure; requirements.txt keeps the ranges. DEVELOPMENT.md covers setup, the same-host and trusted-LAN Ollama configurations, and how to re-run the offline proof. PROVENANCE.md records the upstream commit, the MIT terms, and both vendored assets. Verified, not just compiled. On an --internal Docker network with 1.1.1.1 unreachable and no name resolving, a campaign was created and played for six turns through same-host Ollama, restarted, and resumed. A second run played ten turns through Ollama on a separate physical machine on the LAN over verified HTTPS, summaries and embeddings included, with the storyteller's default route deleted so the LAN was reachable and the Internet was not. Its capture: 893 packets to the approved host, 730 loopback, zero anywhere else, and zero DNS queries. Two induced model failures left the accepted story bit-identical. The inherited SPA was opened in a browser and a campaign read back from it. Evidence is in planning/reports/M1-BASELINE-REPORT.md, along with the findings that did not belong in this change. 648 backend tests pass, up from the inherited 632; frontend lint and build are clean; the image builds. No M2 work is included: the hosted, cloud, analytics, Postgres and scripting surfaces are untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017foPNqFjAJa2Ngebf5mEfL
48 lines
2.2 KiB
Python
48 lines
2.2 KiB
Python
"""Verify TLS against this machine's own trust store as well as certifi's.
|
|
|
|
`httpx` verifies against the `certifi` bundle, which carries the public web's
|
|
certificate authorities and nothing else. A trusted-LAN inference host often
|
|
has no public certificate: on a StartOS server, Ollama is served over HTTPS
|
|
with a certificate from a local CA that the user installs on the machines they
|
|
use it from. `curl` and the browser accepted such an endpoint; this
|
|
application refused it:
|
|
|
|
Connection failed: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify
|
|
failed: self-signed certificate in certificate chain
|
|
|
|
That is a wrong answer for the deployment this project targets
|
|
(`planning/DECISIONS/002-ollama-only-v1.md`), because the user had already
|
|
made the decision to trust that CA, at the level where such decisions belong.
|
|
|
|
So the rule is the one a user already expects from everything else on their
|
|
machine: **a CA installed on this host is trusted by this application.** This
|
|
is not a relaxation of verification. Certificates are still verified, hostnames
|
|
are still checked, and a certificate signed by nobody the machine trusts is
|
|
still refused — `AIDND_ENDPOINT_INSECURE` and its like deliberately do not
|
|
exist.
|
|
|
|
The two stores are unioned rather than swapped. `ssl.create_default_context()`
|
|
alone would be a behaviour *change* — it loads only the platform's default CA
|
|
locations (`/etc/ssl/certs` on Debian and Ubuntu), and a stripped-down image
|
|
whose system store is empty or stale would start failing on endpoints that
|
|
used to work. Adding certifi on top makes this a strict superset of the old
|
|
behaviour, so nothing that verified before can stop verifying now.
|
|
|
|
Building a context parses every certificate in both stores, so it is done once
|
|
and cached. The result is read-only afterwards and is shared safely across
|
|
concurrent requests.
|
|
"""
|
|
|
|
import functools
|
|
import ssl
|
|
|
|
import certifi
|
|
|
|
|
|
@functools.lru_cache(maxsize=1)
|
|
def ssl_context() -> ssl.SSLContext:
|
|
"""The verification context every outbound HTTPS client should use."""
|
|
context = ssl.create_default_context() # the platform's CA store
|
|
context.load_verify_locations(cafile=certifi.where()) # plus the public web's
|
|
return context
|