Soren Stoutner <[email protected]> writes: > From a security perspective, it makes sense to me that the DD should > create a .dsc and .changes and sign them, and then tag2upload should > create them as well and verify they match exactly.
I don't believe that it's feasible to do this because both tar and a compression program are involved in the process of creating the debian.tar.gz or debian.tar.xz. That means that this problem, as stated, is a variation of the pristine-tar problem -- an easier variation, admittedly, because there is less variance of tooling involved, but still the same class of problems. And as anyone who has been involved in pristine-tar maintenance can attest, this is not an easy problem. What I agree should be feasible is to make the *contents* of the tarballs and metadata files that compose a source package, as unpacked on a file system, identical. This dodges all the problems with unreproducibility in tar and xz/gzip at the cost of making the equality check somewhat more complicated. (For example, timestamp resolution varies by file system, hard links are a thing... there are some obstacles here, but I think it's possible to overcome them.) I also think that providing tools that let people do this check whenever they wish is an excellent idea. As Ian and I were discussing elsewhere in this thread, I think dgit already has a lot of the pieces to do this. I also agree with your point that doing this in two places and ensuring that they match provides a useful security property. This is true for almost any two independent places that would not be compromised by the same attacker. What I disagree with is *forcing* one of those two places to be the uploader's system. This is where I think the design is too inflexible and defeats the point of what tag2upload is trying to do, which is to make the local system less central to the development process. The point of tag2upload is to enable something closer to the Git-first development model that is widely used outside of Debian, where package development happens primarily in the Git repository and the laptops of individual contributors to that development interact with it by being Git clients. I think the action of vetting a Git tree and indicating that it should be uploaded is conceptually separate from the build system that turns that into a source package. Those two things *can* be done on the same computer, but there is no reason to *force* them to be done on the same computer, and there are a few good reasons not to: 1. The uploader's laptop may be running Debian stable, or Debian oldstable, or not Debian at all (I believe we have several folks who work primarily on other distributions but also contribute work to Debian). This doesn't interfere with it acting as a Git client and it doesn't interfere with it signing a Git tag, but it may very well interfere with it building the source package correctly. To work around this, they then have to set up even more somewhat-arcane Debian-specific stuff: an unstable chroot, or unstable Docker images, or whatever. 2. The tagging process is no longer transparent to the uploader. It now involves doing this other extra Debian-specific magic that gets loaded into their signed Git tag but that they probably don't know anything about and can't actually verify is correct, whereas the tag2upload tag is a straightforward set of metadata that can be understood on its own without special tools other than Git. I like the property that tag2upload has of moving us closer to a world where people understand the thing that they're signing, rather than trusting the output of a somewhat opaque build system. (There are some real limits here, of course, because I'm still trusting that Git and GnuPG are doing what they say they are, but at least we've removed a bit of the indirection.) 3. Locking us in to doing this verification on the uploader's system, specifically, is unnecessarily limiting. There's only one uploader, and there's nothing special about their computer that gives it the ability to perform this check better than others. I think it's a lot more interesting to imagine a world in which someone external to Debian runs a separate source package verification and could make available, or even upload to the archive, a signed verification that it found the same Git tag, verified the original signature, reproduced the source package build, and got the same results. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
