Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)
Helmut Grohne writes ("Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)"):
> In other words, I want these formats (source package and tagged git
> tree) to be isomorphic (minus history). This requirement is too strong
> since not every source package will have a corresponding tag, but when
> there is a tag, I want to safely go from source package to tag and back
> again and arrive where I started from.
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.
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.)
> 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.
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).
Note that there are *two* tag objects: 1. the canonical view:
the dgit view tag, which is simply-isomorphic to the source package.
2. the maintainer tag, which is on the maintainer's branch and refers
to a commit in maintainer branch format.
With dgit push these are both made during dgit push with the
maintainer's key. With tag2upload the canonical view tag is made by
the tag2upload service, because it is that service which performs the
maintainer->canonical conversion.
Each maintainer workflow defines a different mapping between
maintainer views and canonical views. The (currently supported[1])
workflows are all isomorphisms. So it is possible in principle to
reverse the maintainer->canonical transformation (if you know the
workflow, which can be found in the tags) but there is not currently
code to do that. I don't get the impression, however, that this is a
thing you feel you need ? (Some form of reverse transformation would
be needed to automatically and workflow-agnostically handle MRs whose
submitter is using the canonical view.)
> This backwards-connection seems to be missing thus far, but I do find it
> important for the reasons above. Adding it would easily allow dak to
> validate the signature on the tag.
So, I'm not sure I understand what you think is missing.
Ian.
[1] I think with monorepo workflows the maintainer->canonical
conversion is generally irreversible, because it discards information
about source packages other than the one in question. This wouldn't
block MR processing because MRs are deltas and by definition the other
parts of the monorepo aren't edited in the MR. It does mean you
couldn't reconstruct the whole monorepo given just the canonical view.
(Arguably this means that the .dsc representation of a source package
from a git monorepo is not a PFM. See arguments on -legal and
-project, passim. But the canonical view dgit branch does contain the
whole of the monorepo in its history, in a discoverable way, so
doesn't have this issue.)
--
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.
Reply to: