Helmut Grohne writes ("Re: Building Debian source packages reproducibly (was:
Re: [RFC] Proposal for new source format)"):
> 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.
That does make sense. This is one of the ways that tag2upload is
better than dgit push. (It is a shame that "integrity" concerns are
blocking integrity improvements.)
It would be possible to write a QA service which would verify Dgit
fields and automatically file RC bugs. So far that hasn't seemed
necessary.
It would also be possible for dgit clone to verify the correspondence
itself, at the point where it honours the Dgit field. Would that be a
useful feature for you ? Of course it does mean downloading the
elements of the source package, which it currently doesn't need to do
if it finds a Dgit field, but there's no real difficulty. (I wouldn't
make this the default!)
> > 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.
Yes. If tag2upload is deployed, I expect it to be very popular.
Until then Vcs-Git has all the problems you mention and many others
too: it is hard to reliably find the right tag (even the tag name is
not formally standardised!) and certainly nothing checks that the tag
corresponds in any particular way. How it might correspond is
generally not even documented anywhere - at least, not anywhere
machine-readable.
> 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.
I think ftpmaster's concerns mean that dak would want the tag object
to redo the uploader identify verification, even though from my point
of view that would be a redundant check. But it's simple to provide
the tag and there is some integrity improvement from doing so, so that
is what I am proposing.
Ian.
--
Ian Jackson <ijack...@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.
