Hi, On Fri, 2024-06-21 at 16:55 +0200, Matthias Urlichs wrote: > On 21.06.24 14:33, Ansgar 🙀 wrote: > > > IMHO tag2upload does not drop integrity checks, for the simple reason > > > that a maintainer who uses dgit today does not perform any such test. > > The change request is for the archive to drop them. > > Umm, no. We're not dropping the check; we required a maintainer's > signature before, and we still do so after. We just place a > packaging-and-possibly-source-mangling server between A and B.
So we drop the integrity check using the maintainer's signature in the archive... > Also it's not an integrity check. It doesn't verify that the files in > the uploaded tarball correspond to either the git tag of the source the > maintainer worked on *or* the contents of their file system when they > ran "dpkg -S". I'm not sure what you are talking about here. If you claim checking a cryptographic strong hash over some data and a cryptographic signature by the maintainer that covers the hash is not an integrity check, I feel like you might have a different understanding of an integrity check than I commonly see. In that case we should step back and look at those definitions first to come to a common understanding of an integrity check. > Fundamentally, the fact remains that when you do a "dgit push-source" > today, dak integrity-checks some tar files that were generated and > signed on a random machine with random and possibly-malevolent software > that could have silently replaced any file it wanted to – files which > you currently can't auto-verify independently and which no human will > examine (unless there's a strong external suspicion of foul play). And that will remain the case: even with tag2upload the maintainer will sign some data that was generated and signed on a random machine with random and possibly-malevolent software that could have silently replaced any file it wanted to... And generally no human will examine most of the code unless there is such suspicion. For example, AFAIU various parts of the xz-utils backdoor were just there in the Git tree and it wouldn't have made too much of a difference to place the last bits there as well. > The source > is now a git tag on Salsa whose history people who work on the code > actually use and examine, the dgit job runs in a VM with defined state, > and the correctness of its output is easily machine-verifiable. Or not so easily as otherwise the archive could simply do it. And people don't work on the tree actually uploaded to the archive and don't even notice whether those trees are identical to or different from the one they might have signed (or even know whether they are identical or different). Ansgar
