Russ Allbery writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Timo Röhling <roehl...@debian.org> writes:
> > Would it be possible for tag2upload generate some sort of log or diff of
> > its operation? Then, a verifier does not have to reimplement the whole
> > dgit logic with all its edge cases, it merely has to apply the same tree
> > transformation(s) as t2u and verify that this will indeed produce the
> > source package from the signed Git tag.
>
> I believe that's what tag2upload pushes to the dgit-repos server, although
> I'm not sure that exactly matches what you're asking for.
Whst gets pushed to the dgit-repos server is:
1. The original tag, made by the maintainer uxing git-debpush.
It's a DEP-14 tag with a bit of additional metadata in the body,
where the tagger declares precisely what and where they intend be
upload.
2. git commits generated automaticallty to convert the signer's tree
to the canonical form and history. For a native package, there are
no commits which change the tree. In the most common case[0] with
a patches-unapplied package in gbp form, the tree-changing commits
are precisely the patches in d/patches[1].
3. There is also usually a synthetic merge commit, making the result
fast-forward from the previous upload. That way the canonicalised
git branch for a particular Debian suite is always ff.
4. A git tag archive/debian/VERSION, on the canonical git view.
This is signed by the t2u conversion system. (When you upload
yourself with dgit, dgit makes a tag like this and signs it with
your key.)
The source package is made by running dpkg-source on the canonicalised
tree, and the system verifies that unpacking that package results in
the very same filesystem tree.
So if you want to see what changes the t2u server made to the package
*contents*, compared to the maintainer's git repo, you can use `git
diff` on the two tags. In the most simple case for a gbp git tree,
the result is precisely the diff implied by all the patches. For a
native package. the diff will be empty: the two tags are treesame.[2]
In an important sense, this git information is a log. It is
append-only: the dgit-repos server does not accept force pushes.[3]
We also plan for the t2u server to email reports to a mailing list.
Ian.
[0] I am eliding many corner cases!
[1] "precisely the patches in d/patches" turns out to be extremely
complicated in the general case. Different maintainer tooling
interprets d/patches differently. dpkg-source and gbp do not agree!
There are maintainer workflows and git trees with partially
incompatible notions!
[2] Because of the ff requirement, and the need to handle uploads not
done with t2u or dgit, the canonical history may need to contain
imports of .dscs. So the histories can differ.
[3] There is an exception for NEW packages, because NEW review may
discover that the history needs to be laundered. We can't do
tag2upload with NEW at all right now because it can only do
source-only uploads.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
