jschoubben
76fcbda9a7
autocert keeps its account key at one fixed name, `acme_account+key`, in whatever directory it is given, and reuses it for ever. That is right while the authority stays the same and silently wrong the moment it does not. Re-initialising the internal CA makes a new authority with a new root: it has never heard of the account in the cache, rejects every use of it, and autocert has no path back from that. Nothing is re-registered, no order ever reaches the CA, and issuance stops with nothing saying why — until somebody guesses that deleting the cache directory by hand is the answer. Name the directory after the authority instead of sharing one between all of them: a digest of the ACME directory URL and the root this proxy was told to verify it with. A re-initialised CA has a new root, the mesh delivers it as a changed bundle, the proxy restarts on that file and lands in a directory with no account in it, so autocert registers afresh and orders again. The healing is that "is this account still valid" never has to be asked — an account is only ever found where it is still valid, which needs no error codes, no probe at startup and no network call that can itself fail. It closes a latent one of the same shape: pointing ACME_DIRECTORY at production after testing against staging reused the staging account, because the cache had no idea the two were different. Trailing whitespace around the delivered root is not a new authority — the mesh writes that file, and a newline coming or going must not throw away an account. Old directories are left on disk, unused: they hold the only copy of certificates that may still be valid, and this program is not the thing that should decide a certificate is finished with. A proxy already holding certificates orders them once more on the first start after this, because its account moves. Free against the lab's own CA and against staging; one issuance per name against a public authority. novox/hq ADR 0056 Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
examples
Things that run, kept here because a contract is easier to read as working code than as prose.
Nothing here is part of the control plane. The control plane decides and never touches a machine (README); everything in this directory runs on a machine and touches it. These are reference implementations of contracts the control plane defines, and a real one ships with the module that ships the software it configures.
postgres-provisioner |
the last step of a credential: reads what the mesh delivered and makes PostgreSQL accept it |
Running the provisioner
--watch reconciles now and again whenever what the mesh delivered changes. That is what lets it
be a module: an ordinary long-running service the host supervises, rather than something that has
to be invoked after every declaration by a timer or a unit wired to a file.
It polls rather than watching the filesystem, because the host writes atomically — the file is replaced, so a watch on the path stops seeing anything after the first replacement. A watcher that silently stops working is worse than a poll.
Credentials are compared by digest and never by content. This runs for as long as the machine is up, and a secret does not belong in a long-lived variable when a hash answers the same question.