Re: tag2upload service architecture and risk assessment - draft v2
On Wednesday, August 28, 2019 7:10:44 AM EDT Ian Jackson wrote:
> 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.
This is an example of where I struggle with 'assume good faith'.
Several time people have said they feel it's important to be able to verify
from contents of the archive. Your response seems to me a consistent 'meh,
not important'.
My view of this seems to come from the opposite perspective of yours. A git
commit is a reference to a set of code at a given time. What the uploader
intends to release is not "some git commit". It's code. The fact that it's
in git or not is a minor implementation detail.
Today the authoritative repository for what's in Debian is the package
archive. My read is you want to change it so that the package archive is an
implementation detail hanging off of a set of git repositories and I am not at
all comfortable with this concept.
Your proposal completely changes the notion of what our package archive is
while, IMO, pretending to be something else.
I don't necessarily assume bad faith, but it feels like you are so convinced
of the righteousness of your approach that you are having trouble taking
concerns seriously.
I think I don't have a lot more to contribute on the topic.
Scott K
Reply to: