Skip to content
andrew.dunn.dev

kit

Source

kit managed a developer toolchain as a supply chain. A tool definition was a small TOML file: name, source (GitHub, GitLab, npm, crates.io, a direct URL, rustup or Homebrew), version, per-platform asset names, where the checksum lives, and a signature method where the publisher signs. A registry was a git repository of those files under tools/. kit resolved them across every configured registry, wrote mise configuration, and verified what mise installed; CI kept the versions moving.

writes the pin backPINNEDregistryTOML tool defKITresolvemise configSIGNATURE OR SUMverifythen installCI PIPELINESproposenext versionMERGE GATEmergesums re-checked
Registry-pinned install and bump loop
  • Every version kit installed came from a pinned registry definition.
  • Every bump returned to that registry as a merge request, re-checked before it landed.

With several registries configured, declaration order settled a tool defined twice; the loser was logged as shadowed. Each tool carried a trust tier, own, high or low, a judgment recorded once in its definition. The tier decided review, not verification: a registry’s _meta.toml named which tiers and bump sizes could merge without a person.

Verification followed the definition instead: cosign keyless verification against an anchored certificate identity, or a GitHub artifact attestation, where the publisher signs bare binaries; otherwise a SHA-256 comparison against the checksum file, npm integrity hash or multi-column checksum listing.

merged MR updates the pinHOW A PINNED TOOL BECOMES AN INSTALLED BINARYHOW A NEW VERSION GETS PROPOSED AND PROVEDTOML DEFS IN GITregistriessource, version,per-platform assets,checksum, signatureDECLARATION ORDERresolutionreads several at oncefirst declared winsloser logged shadowedGENERATEDmise configkit writes, mise runsone file, all backendsbrew installed outsidePER DEFINITIONverified installcosign keylessGitHub attestationor SHA-256 checksumUPSTREAMreleasesGitHub, GitLab, npm,crates.io, rustup, Homebrewcompared with each pinned defPIPELINE 1 · SENSEsenseclassifies risk: bumpsize, tier, checksumnever fails on driftPIPELINE 2 · RESPONDevaluatenon-major bumps passif checksums verify,model sees edge casesPIPELINE 2 · RESPONDapplywrites the TOML;auto-merge group andreview group, one MR eachPIPELINE 3 · VERIFYverify-registryre-checks everychecksum on the MRbefore it can merge
Install path and the three CI pipelines
  1. Sense runs on a schedule, reads upstream releases, downloads assets, computes checksums and classifies each finding by bump size, tier and checksum status; drift never fails it.
  2. Respond evaluates, then applies: rules pass any non-major bump whose checksums verify and reject a checksum mismatch; a small model sees only the edge cases, never a release note. Approved updates land in the TOML files, split into an auto-merge group and a review group, one merge request each.
  3. Verify runs on the merge request, re-validating every definition and re-checking every checksum; the auto-merge request merges itself once it passes.

Trust lives in the registry, not on the machine. That is the shape immutable applies one level down, at the operating system: pin it, verify it, track what moved.


Created Apr 2026 · Archived Jun 2026
Retrospective →