Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Scott Kitterman writes ("Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)"):
> Effectively tag2upload would replace DAK as the entry point for
> packages into the archive (the equivalent to the current source
> package signature verification being the git tag signature
> verification).  I don't think the discussion got to a point where a
> path forward that was considered reasonable by both the tag2upload
> developers and the FTP Masters was reached.

The current tag2upload proposal includes providing dak with the signed
git tag object so that it can re-verify the identity of the human DD
who authorised the upload.

The sticking point, as I understand it, is that this still does not
allow dak to verify that the *contents* of the .dsc were as intended
by the uploading human. [0]

In the tag2upload proposal, the conversion from git tag to dsc is
`merely' done by an official Debian service on an official Debian
machine, and is `merely' fully reproducible and auditable.

But this is not good enough for some ftpmasters, who want that
verification to be done *by dak*.  Various people attempted in the
previous thread on this topic to find out *why* this is thought
important, without apparent success.

It would be nice to be able to work around this objection somehow by
writing more code.  Unfortunately, any alternative - such as that
described by Didier earlier in this thread - has undesirable
properties.  In particular, it does not seem that it would be possible
to do anything along these lines without continuing to burden the
developer's working system with a whole pile of messing about with
tarballs and quilt and so on.

For example, you would not be able to do this:
   git clone salsa:something
   cd something
   make some straightforward change
   git tag    # } [1]
   git push   # }
Instead you would have to download the .origs and so on, and wait
while your machine crunched about unpacking and repacking tarballs,
applying patches, etc.

With tag2upload all that work is done for you on the tag2upload
service, which of course has a fast network connection - and you don't
need to wait for it.

Ian.

[0] Currently, of course, this requirement is not achieved for
existing git based uploads.  In practice, DDs use ad-hoc
git-buildpackage runes on their local machine to convert git data into
.dscs.  That conversion is not controlled, not reproducible, and not
practically auditable.  I guess maybe those blocking tag2upload think
it is sufficient that we can blame the DD if it is messed up or
suborned ?

[1] In practice with tag2upload you would use `git-debpush' instead of
`git tag' + `git push' but this is a thin wrapper around `git tag' and
does not involve downloads or indeed any network activity, etc.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.