On Sun, 30 Jun 2024 at 20:47, Scott Kitterman <deb...@kitterman.com> wrote:
>
> On Sunday, June 30, 2024 1:45:15 PM EDT Aigars Mahinovs wrote:
> > On Sun, 30 Jun 2024 at 19:28, Russ Allbery <r...@debian.org> wrote:
> > > Aigars Mahinovs <aigar...@gmail.com> writes:
> > > > Correct me if I'm wrong, but I believe the intention is to have two
> > > > technically redundant data points saved into the archive:
> > > >
> > > > 1) checksums of the contents of the shallow copy git tree in the
> > > > maintainer work folder (signed by the maintainer)
> > > > 2) contents of the shallow copy git tree in the t2u server work folder
> > > > (signed by t2u)
> > >
> > > Oh! Did I misunderstand Joerg's second point entirely? By "the tag that
> > > t2u wants to upload," I assumed that meant the tag the uploader signed or,
> > > in other words, the state of the tree *before* t2u started doing its work
> > > that has the uploader signature attached.
> >
> > I do not see that in either what me or Joerg wrote. And I also don't
> > see much sense in that.
> >
> > In contrast, having a tarball of the git state *before* t2u starts its
> > work would provide a tarball that *can* be verified against the
> > checksums from the first file. That will give you a clear data point -
> > t2u started its work with the exactly the same workspace as the
> > maintainer signed. And will provide a frozen copy of that starting
> > workspace in the archive independent of the (more complex) dgit
> > service.
>
> It's one at the point the maintainer signed the tag.
Yes, but I would like to point out the difference. It's where and when
this tarball is created.
The Debian developer/maintainer creates a signed git tag that contains
(in its message, presumably, to avoid adding new communication lines)
the file listing of the git checkout at the point of signing
(including file names, modes and short SHA checksum hashes). This
extra content is added at the end of the tag message, after the other
metadata that t2u proposal/code already defines. This tag is pushed to
a git server that t2u is monitoring. No files or tarballs are created
at this point yet. No files or tarballs leave travel out of the
developers computer. Only the signed tag with a (now quite long)
message.
t2u starts its work by checking out the git tag and saving two files:
1) the tag message with the corresponding Devian developer/maintainer
signature, so it can be checked outside of git (can this be done
easily?)
2) tarball of the git clone before anything is done to it - filesystem
tree in this tarball will be (presumably) the same as what was in the
workspace of the maintainer when they signed the tag
Both t2u and dak may check this equivalence at any time in the
process. The contents of the listing in the tag *should* match the
file tree content of the checkout that t2u gets from git. If that does
not match, then something fishy is going on and the upload should be
aborted.
After that t2u does all its processing, pushes the unified git tree to
dgit, constructs the source packages, signs the source package and the
new two files and sends it all to dak.
IMHO that all makes sense and does not block anything while providing
useful features, like a frozen git snapshot in the archive. Please
correct if I got anything wrong. This is getting into lower level git
and t2u details that I am barely competent in :D
--
Best regards,
Aigars Mahinovs mailto:aigar...@debian.org
#--------------------------------------------------------------#
| .''`. Debian GNU/Linux (http://www.debian.org) |
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `' Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--------------------------------------------------------------#
