Hi all, Liliana Marie Prikler <liliana.prik...@gmail.com> writes:
> Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver: > >> If upstream later indicates that version "1.2.3" is now commit YYZ, I >> don't think that invalidates our basis for continuing to associate >> version "1.2.3" with commit XYZ. The aforementioned immutable >> historical fact still remains our basis and justification for making >> that association. > > I'm pretty sure it does, particularly to a future observer who may not > have the luxury of a history to distinguish that record from one in > which a malicious committer linked those versions and tag together and > then no one bothered to check. If you want a concrete example to think through, there’s ‘eclib’. Our package says it’s version “20190909”, but that’s not what upstream calls version “20190909”. It looks like when we packaged ‘eclib’, that tag pointed to commit 19e7e3e74268bf78bd9a1c4ba07597d5434fb166, but now it points to bfbbd7c414521e1bf5e718a2925ea8ad845a2e87. If you try to build ‘eclib’, everything will work great, since we can grab the checkout from our servers. If you use $ guix build --check -S eclib you get a hash mismatch. We have CI jobs for sources, but they aren’t checking this: <https://ci.guix.gnu.org/build/319/details>. That job succeeds after downloading the checkout from our servers. There are two things I can highlight from this case. First, as expected, finding the original commit was painful. SWH did not record the old version of the tag. Comparing it with the checkout from our servers showed that the differences were very minor. With that in mind, I moved backwards through the commit history with ‘guix hash’ until I found a match. As pointed out many times, if I had the original commit, I could just ask SWH for it directly. Second, these cases are very, very rare. (I’ve essentially checked every Git origin since Guix version 1.0.0, and this problem is not one that worries me). “Tricking Peer Review”-style problems seem to be much more prevalent. When tracking down a “difficult” Git origin, the first thing I do is grep the Guix Git history for a “oops I committed the wrong hash” message. I recommend we focus our energies there before worrying too much about replacing tags with commits or using both or whatever. >> Regarding "Tricking Peer Review": I think it would be ideal for >> package definitions to include both the git tag _and_ the git commit >> hash, and to teach our linter to raise an alarm when the expected >> tags are missing or fail to match the expected commit hash. > > That is among the solutions I've proposed here, so naturally I'd be > fine with it. Given what I wrote above, maybe we could start by updating the linter so that ‘check-source’ actually checks that it gets the right result. Right now it uses a few heuristics to check that the result looks okay (for instance, it checks if the result is suspiciously small). Maybe it should just go through the whole download process and verify the hash? Alternatively (or additionally), the CI “source” specification could be configured to avoid using our servers as a fallback when checking sources. I agree that adding more identifiers (commit hashes or whatever) makes things more robust, but the cost is more work when creating, updating, and reviewing packages. I think we should start by verifying the identifiers we already have (i.e., checking that the URI and method of the origin produce the right output). It would solve many existing problems and would serve as a nice foundation for future improvements. And as a bonus, if you want to be really kind to future time travellers, when fixing an errant hash, please include a nice hint as to what the original hash was for (like a commit hash). We have commit ca5a791f6285b08506ccd662d5911ccf0c4d1ece in our repo, which says: > The previous hash was from the "dev" branch of the repository. I can’t find the source for the previous hash, and if I could actually travel through time, I would change the commit message to: > The previous hash was from commit abcd0123..., which comes from the > "dev" branch of the repository. :) -- Tim