Re: tag2upload service architecture and risk assessment - draft v2

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

Bastian Blank writes ("Re: tag2upload service architecture and risk assessment - draft v2"):
> We don't want to be forced to trust ftp-master.  We have reproducible
> builds to verify the content of binary packages.  We have the user
> signatures to verify source packages.  Of course none of this are
> foolproof or will work all the time.
> 
> Right now the team delegated to keep the archive running and safe is not
> willing to drop the ability to verify the contents independently.

These kind of considerations are why in my proposal the .dscs are
reproducible from the uploader-signed git tags.

Tracing the archive contents back to uploader signatures is already
complicated because of the difficulty of understanding what an
appropriate maintainer signing key is for any particular .dsc.  With
my proposal it indeed becomes more complicated.

But I have to ask:

Is the uploader signature on the .dsc really the thing we want to
trace the .dsc back to ?  Usually nowadays the uploader .dsc signature
is made on the output of some git-buildpackage rune (or automatically,
by that rune).

Typically the human uploader doesn't intend to release some particular
.dsc; that's an output artefact.  The uploader intends to release some
git commit.

So the .dsc should be traceable to that git commit.  Currently it is
not.  With my proposal the .dsc is traceable to the git history,
including the uploader's signed tag.

Ian.

-- 
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.