On Sun, 30 Jun 2024 at 17:58, Russ Allbery <r...@debian.org> wrote:
> > The second file consists of a shallow git clone of the repository for
> > the tag that t2u wants to upload, put into an appropriately named
> > tarball.
>
> Just to double check, to make sure I'm not missing some subtlety, it's
> intentional that this file contains all of the same information as in the
> first file, and the first file is just a subset of this same information
> in a different form?
>
> In other words, someone could verify the signature on the Git tag in this
> file and then run the git ls-files command on the Git repository and get
> exactly the same information as in the first file, so the first file is
> technically redundant. I can think of some reasons why you might want
> that, but it's a little surprising, so I wanted to make sure that's
> intentional.
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)
Sure, it does not encompass the full source info in many git
workflows, but it does seem to add some defence against tag collision
attacks. And provides a server-independent source code copy for easier
archival.
The only suggestion I would have here would be to have the shallow git
clone on the t2u side have a variable depth that is selected so that
the commits in the resulting depth are sufficient for the source
package construction, like in case of a rebase workflow you'd need to
have git history deep enough to include all Debian patches and the
last upstream commit.
--
Best regards,
Aigars Mahinovs
