Gard Spreemann writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> I have not more than skimmed the architecture, so forgive me if this
> makes no sense: Could this fear (whether overblown or not) not be
> alleviated by including in the tag2upload structured metadata a SHA-256
> hash of all the files in the given commit?Notwithstanding Sean's comments, I think it is worth responding to this. It's an obvious suggestion that we ought to discuss and dispose of. And it relates to key points of dispute. Yes, it would be possible to have the git tag contain a complete SHA256 manifest of some kind. We (Sean and I, the tag2upload developers) have considered this option and rejected it, for the following reasons: 1. It is an important property of tag2upload that the git tag is really just a git tag. [1] This has a number of important consequences: * The tag can be generated by a variety of software, even by hand if you want to. * The tag can be fully parsed and checked easily, with git-verify-tag, optionally with some scanning it for desired metadata, not only processed by complex bespoke tooling. * The tag can be reviewed by a human and everything in it is transparent. * Reusing git's existing semantics greatly simplifies the model. Overall, we very much want tag2upload to be as close to "normal git" as possible. We're trying to get rid of some of Debian's needless weird shit. [2] 2. Typically, generating such a SAA256 manifest would be hard (!) Usually, this suggestion is combined with the notion tha dak would be able to verify the manifest. This means that the SAH256 manifest must contain the hashes of the files in the .dsc. But git to .dsc conversion is astonishingly complicated. (Even most Debian maintainers greatly underestimate how complicated it is to do this well in the general case. We, the dgit maintainers, have discovered all of this the hard way.) Source package construction can requires out-of-git data that the uploading system doesn't even have, and which is a pain to manage, such as orig tarballs; it can involve strange patch application processes (search dgit.git/dgit for "absurd" and you'll see some of what I mean). It can be very slow. A key benefit of tag2upload is to get rid of all this crap [2] from the uploading user's machine. Having the user's machine effectvely create and discard a source package defeats most of the point. The alternative would be a SHA256 manifest of the git tree. That would work and be only moderately annoying. But it is a pretty ugly bodge, which exists only as a kind of stopgap pending git sha256 transition. dak wouldn't be able to verify the manifest. 3. Overall, we don't think the risk from SHA-1 is worth such countermeasures. Russ's review deals with this at length. I hope this helps explain. Ian. [1] You can see the specfication for the metadata here https://manpages.debian.org/testing/git-debpush/tag2upload.5.en.html [2] Yes, I'm being very rude about Debian source packages. I think I am allowed, since I invented them in 1992/3. They were a good idea at the time (as `3.0 (quilt)` was in its day) but nowadays we have git. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
