Ludovic Courtès writes: >>> Second, even if it did, it would be a shallow check: as Mike notes in >>> <https://mikegerwitz.com/papers/git-horror-story> with the ‘signchk’ >>> script, you actually have to traverse the whole commit history and >>> authenticate them one by one. But that’s OK, it runs in presumably less >>> than a minute on a repo the size of Guix’s, and we could also stop at >>> signed tags to avoid redundant checks. >> >> Practically speaking, that's probably fine, though note that a signed >> tag is just a signed hash of the commit it points to (with some >> metadata), so you're trusting the integrity of SHA-1 and nothing >> more. >> >> With that said, the tag points to what will hopefully be a signed >> commit, so if you verify the signature of the tag _and_ that commit, >> that'd be even better. Git's use of SHA-1 makes cryptographic >> assurances difficult/awkward. >> >> An occasional traversal of the entire DAG by, say, a CI script would >> provide some pretty good confidence. I wouldn't say it's necessary for >> every pull. > > Agreed.
One theoretical optimization: if I verify the DAG, could I store somewhere that I've verified from commit cabba6e and upward already, so the next time I verify it only has to verify the new commits? Mostly makes sense if we're already going down the only mildly crazypants direction of implementing our own tooling :) - Chris
