Re: [RFC] General Resolution to deploy tag2upload

[Russ Allbery <rra@debian.org>]

Soren Stoutner <soren@debian.org> 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 (rra@debian.org)              <https://www.eyrie.org/~eagle/>