Robonaissance

Robonaissance

AI Grew Up on Git, Part 8: What Version Control Controls

A hash never promised the code was good. It promised the code was unaltered. Twenty years and one industry-wide effort later, that is still the whole promise.

Hugo's avatar
Hugo
Aug 22, 2026
∙ Paid

This is Part 8 of AI Grew Up on Git, a series on the Git infrastructure that raised AI and what AI is now doing to it.


Part 1 of this series opened on a small company revoking something a community depended on, and a programmer who responded by building a version control system on one idea: a hash is a name that cannot lie, and a chain of hashes lets strangers trust a history without trusting whoever holds it. That was never a small claim. For the tool underneath nearly all of modern software, it was the entire claim.

Every part since has been the same promise, tested against something it was never built for. GitHub’s social layer. A model’s weights. A decade of scientific claims. A $7.5 billion acquisition nobody understood the value of until years later. The diff itself, refusing to run on model weights at all. The identity of an author who might not be a person. In each case the promise didn’t break. It got stretched, by hand, one workaround at a time, and the workarounds are the real subject underneath all of it.

This part asks what’s happening to that promise right now, this year, while it’s still being decided.

Signing the thing Git could never hold

Across 2025 and 2026, Google’s open-source security team, the Sigstore project, and the Open Source Security Foundation built something with a name that doesn’t bother being clever: Model Signing. The idea is Git’s idea, aimed for the first time directly at the file Parts 3 and 6 of this series spent two parts proving Git could never really hold. Sign the model when it’s trained. Verify it every time it’s used. That’s the whole design, in the words of Google’s Mihai Maruseac, one of the engineers who built it.

The mechanism updates Git’s original trick rather than replacing it. There’s no long-lived private key for anyone to lose or steal. A publisher’s identity gets a short-lived certificate tied to a login, the signature lands in a public, append-only log anyone can check without asking permission. It is Part 1’s tamper-evident chain, generalized past a single repository into a shared public ledger that no single party controls. It is not a pilot project sitting in a lab. Google partnered with Kaggle to sign models automatically at upload. NVIDIA integrated the same approach into NGC. Two of the largest model hubs in the world quietly started doing, for weights, the thing Git has done for text since 2005.

Name what this closes. The gap Parts 3 and 6 spent so much time describing, a file Git could hash but never meaningfully compare, just got the other half of Part 1’s original promise applied to it directly, not laundered through a pointer trick. The industry is rebuilding, in public, by hand, the exact thing Part 1 started twenty years ago.

A signature that worked, and still signed an attack

On May 11, 2026, between 19:20 and 19:26 UTC, six minutes, that same family of protection failed in the most instructive way it could have.

Attackers published 84 malicious versions across 42 packages belonging to TanStack, a widely used piece of open-source JavaScript infrastructure, through TanStack’s own legitimate release pipeline. Nobody’s password was stolen. No npm token was stolen. The attackers chained three separate, individually known weaknesses: a pull request that ran with more trust than it should have, a poisoned build cache waiting for the real release process to restore it, and code that reached directly into the release runner’s memory to extract the short-lived credential the legitimate pipeline itself had just been issued. When that pipeline published, it published exactly what it was supposed to trust.

The result was the first documented attack in npm’s history to carry fully valid, cryptographically verified build provenance. The signature was not forged. It was correct. As one security newsletter put it precisely, in the exact week this was happening: provenance attests pipeline identity, not pipeline honesty.

The attack didn’t stay contained. A week later, a completely unrelated project, a popular code editor extension, shipped a compromised release of its own, traced back to a single contributor whose own machine had quietly installed one of the poisoned TanStack packages seven days earlier. The broader campaign spread to roughly a hundred and sixty packages across two ecosystems within about a day. Trust, once it slipped, moved through the same channels that make open source work at all.

The cleverness of the attack isn’t the point. The point is what TanStack’s own maintainers said afterward, in their own names, in their public account of what they’d rebuild. The parts of their security posture they’d actively invested in, trusted publishing, two-factor authentication, signed commits, were not the part that failed. The part they hadn’t hardened was the automation running underneath all of it, and that is what they went and fixed. A cryptographic signature has only ever proven one thing: that a specific process produced a specific artifact. It has never once proven that the process, or the artifact, deserved anyone’s trust. Git’s hash never promised the code was good. It promised the code was unaltered. Nothing about a year of real, serious, well-built signing infrastructure changed that promise’s actual size, and mistaking it for a bigger one is exactly how a correct signature ends up certifying an attack.

None of this is an argument against the work in the previous section. It’s the argument for why that work is only half of rebuilding trust, and it was always the easier half.

User's avatar

Continue reading this post for free, courtesy of Hugo.

Or purchase a paid subscription.
© 2026 Robonaissance · Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture