Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)
Hi Ian,
On Tue, Oct 29, 2019 at 12:54:57PM +0000, Ian Jackson wrote:
> I wonder if I have misunderstood you, because:
>
> The tag2upload proposal is based on dgit, which already provides this.
> dgit indeed defines an isomorphism between source packages and git
> trees, and dgit clone gives a git branch that is thus-isomorphic to
> the .dsc. This is fundamental to dgit's design.
I get that this is the intention, but I don't see that this property can
be safely assumed. I see the Dgit field as a hint. It says "this source
package should be equivalent to this commit" without any guarantees of
this actually being the case. I guess that for all uploads performed
thus far, this is indeed the case, but it is not a requirement validated
by dak or any other trusted (by me) entity. We could easily end up with
an upload where the commit id is accidentally different. Everything that
we can be gotten wrong, we will eventually get wrong.
> With `dgit push', the isomorphism is checked on the maintainer's
> machine during `dgit push'. With tag2upload it is ensured by the
> tag2upload service. (When the uploader didn't use dgit, dgit clone
> does a .dsc import, thus ensuring the isomorphism.)
I think I'd trust the tag2upload service given the documentation you
presented about it. I'm less faithful in all dgit installations being
sane, sorry. We've run into too many builds in dirty chroots already.
> > This property allows me to start from a git tree that is
> > authenticated by dak rather than a random git tree on a random git
> > server of questionable origin.
>
> You do not need to talk to any random git servers. The git tree is
> available on a single official Debian server, the dgit git server.
> The Dgit: field in the .dsc identifies the commitid. The .dsc is of
> course available via the signed apt repositories, as well as being
> available from the ftpmaster data API.
I was not trying to imply dgit to be a random git server. Given that
dgit (currently) only contains history for a fraction of packages, we
still need to compare with Vcs-Git. Given enough time, dgit will have
useful histories eventually.
> It is true that this doesn't give you precisely the *tag* object -
> just the commit. Adding the objectid of the tag object to the .dsc
> Dgit: field would be easy, if that would be helpful to you. (Please
> file a wishlist bug against dgit if so.) Alternatively, dak could
> publish the tag object (in a similar way to how it publishes binary
> buildinfos).
Hmm. I'm not sure whether I actually need the tag object. The commit id
is what I really need. dak might need the tag object. I'll defer to
others.
Helmut
Reply to: