[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On October 28, 2019 5:53:00 PM UTC, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
>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.
>[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.

And the talking past each other surely continues because I don't think that in any way answers the objections.  Repeating the same thing you've said before isn't going to close the communication gap.  I don't think it's possible to do so right now.  Also, I'm a mere FTP Assistant, so I'm not one of the ones you have to convince.

Scott K

Reply to: