[earakely-scale]

What and why

M5.4 (FD-4933): every program on a deployed Linux computer that checks TLS certificates trusts the deploy's CA, however it was started: browsers, the system store, Node, Python, programs reading SSL_CERT_FILE (Go, Ruby, OpenSSL tools) and Java. M5.7 (sites by name over HTTPS) and M5.17 (apps that depend on sites) need any app in the computer to load https://<site>/ without certificate errors. #448 shipped the CA itself and most stores; the outcome and four decisions are on FD-4933, decisions 1 and 2 revised once the local provider's trust files turned up. Site routing stays Linux-only here, shaped so macOS and Windows can be added: they're M6.6 (FD-5335).

• The gap this closes: the trust variables lived only in /etc/profile.d, which only login shells read. Apps launched at boot or from the menu, and computer-exec commands not run through a login shell, never saw NODE_EXTRA_CA_CERTS or REQUESTS_CA_BUNDLE, and nothing set SSL_CERT_FILE.
• One convention for the trust agentenv adds (decisions 1 and 2): the local Docker provider already copies its transfer CA into containers as /etc/agentenv/ca.pem and /etc/agentenv/ca-bundle.pem (the public roots plus it) and points the three variables at them. That's now the convention for the sites CA too: /etc/agentenv/ca.pem holds every CA agentenv adds and is the fixed path the design names for an app with a certificate list of its own; ca-bundle.pem holds the public roots plus them. A computer routing a site served over HTTPS boots with the same variables, so every process inherits them; one routing only .localhost names, for which no CA is made, boots without them. The files and variables are kept per OS type (sites.TRUST_ENVIRONMENTS), whose Linux entry is the provider's LOCAL_TRUST_ENV, so the two can't disagree. Routing appends the CA to both files; both are readable by everyone. The profile script now sets the same variables, sent from the same table, for shells that start a fresh login environment.
• The files exist from boot: the ubuntu-24.04 and ubuntu-24.04-headless images ship an empty ca.pem and ca-bundle.pem as a copy of the system bundle. An app's services start at boot, before routing, and inherit the variables, so until routing appends the CA they get the public roots instead of a missing file. A local run's provider still copies its own files over them.
• The bundle is made again at routing: routing makes ca-bundle.pem from the system's file of public roots as it is then, plus every CA in ca.pem (a provider's and the sites'). That file is Debian's (/etc/ssl/certs/ca-certificates.crt) or Red Hat's (/etc/pki/tls/certs/ca-bundle.crt), and update-ca-certificates has just added the sites CA to it. So the bundle also holds any CA a composed app added to the system store after the image was built. On a Linux with neither file, routing keeps the bundle the image or a provider made; with no bundle either, it's refused, naming both files, rather than leave a bundle of the CA alone, which would break public HTTPS for every program reading SSL_CERT_FILE.
• Refused off Linux: site routing is refused at save and at deploy on a computer that isn't Linux. A macOS computer wasn't refused before, but the install only knows Linux and would have applied part of it; Windows computers were already refused through their disk form.
• Java (decision 3): apt JDKs trust it through ca-certificates-java's hook, which update-ca-certificates runs; every other JDK under /usr/lib/jvm, /opt and the app folders gets it with keytool, its own else any. Each store is checked with keytool -list for the CA's SHA-256 fingerprint and recorded in trust.java.
• Checks (decision 4): besides each site through Python's system store, the install loads the first HTTPS site through Python with SSL_CERT_FILE alone, and through Node and curl where the computer has them, as the session user. Each result is kept in the deploy record's sites.runtimes, and any runtime or JDK store that fails fails the deploy, naming it.
• Universe-clock validity stays waiting on the clock work.

How it was tested

• ruff check: clean.

• Unit tests: test_computer_site_proxy.py: the install writes the shared trust files and the profile script, its bundle from Red Hat's public roots; the CA joins files a provider made, idempotently, or a bundle started from the system's; the bundle is made again from the system store, holding a CA an app added after the image was built and a provider's CA from ca.pem; an empty bundle with no public roots to start from is refused before either file is written; JDKs: an apt one through the hook store (listed only), a downloaded one and a bundled one without keytool (imported), a link to the same store once, a store whose password differs and one the CA isn't listed in (each named); the runtime checks, with SSL_CERT_FILE unset named. test_computer_sites.py: each failure named; Linux's trust variables equal the local provider's. test_computer_env.py: a routing computer boots with them, one without routing doesn't; the route is given the computer's OS type. test_computer_vm_bundle.py: site routing into a macOS computer is refused, at save and through the check the deploy runs. tst/unit/env and tst/unit/providers: 3929 passed; the one test_disk_recipe failure fails on macOS only.

• VM e2e, agent-environments-admin, amd64 and arm64: a new test bundle, tls, whose clients app installs Node, an apt JDK and curl, copies the JDK under /opt with a store of its own, and, launched at boot, loads its URL through each. With a site routed into the computer, ca_trust_test.py checks that:

  • the app launched at boot loaded the site through Node, both JDKs and curl;
  • a command the computer runs sees the three variables and loads the site through Python with SSL_CERT_FILE alone;
  • /etc/agentenv/ca.pem holds the CA, mode 644, and /etc/agentenv/ca-bundle.pem holds it beside the public roots;
  • the record keeps each runtime's check and both JDK stores, trusted.

  The routed-site and start-tab tests from M5.12 run again beside it. On f47f064 all 5 passed on both arches (about 14 minutes each). The composed images carry the two files from build: an empty ca.pem and ca-bundle.pem with 120 public roots, both mode 644. After Greptile's round-3 finding (the image's copy would miss a CA an app adds), the bundle is made again at routing; on ece919c the CA trust test passed again on both arches.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; no blocking issue remains.

Summary

The PR gives Linux computers shared CA files and trust settings for browsers, Python, Node, curl, and Java.

• Linux computers pass the deploy’s CA trust to apps started in different ways.
• Site routing now rejects computers that are not running Linux.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Shared Linux trust settings] --> B[Computer boot environment]
  A --> C[Fresh routing config]
  C --> D[Install CA in trust stores]
  C --> E[Write login shell exports]
  D --> F[Check sites and runtimes]

Loading

_{Reviews (8) · Last reviewed commit: "refactor(computer): the profile script s..." · Reviewed by Greptile}