Re: [RFC] General Resolution to deploy tag2upload
Hi,
On Tue, 2024-06-18 at 18:25 -0700, Russ Allbery wrote:
> Ansgar 🙀 <ansgar@43-1.org> writes:
>
> > A downside is that integrity verification and third parties (possibly)
> > verifying the data falls flat. For me integrity verification would be
> > somewhat nice and third parties a bit less interesting (given they can
> > get the tag, compare files and possibly redo what tag2upload does if
> > they also care about .dsc and stuff).
>
> Integrity verification of the source package construction by dak was the
> part of this that I was the most worried about, because that's the place
> where it had looked like the tag2upload goals couldn't meet the FTP team's
> requirements. If that's something that can be relaxed, that's huge for
> being able to find an implementation that hopefully makes everyone happy.
I don't think it is hard to include that as well. Just include a hash
similar to [1] in the signed tag data; it might need minor changes if
one cares about file permissions[2].
That is a strong hash, easy to implement and if people like entering
upstream commit ids manually into Git tags then they can also run the
equivalent command manually. They already have to manually look up
matching upstream commits and tags[3] and very carefully write a
specially formatted tag. Most people will likely use git-debpush which
could most easily do this.
It is also easy to change to a different scheme, already supports Git
LFS[4], ... It doesn't require dak to reproduce whatever steps
tag2upload runs to generate the .dsc from that or source packages to be
reproducible; the uploader only needs to know which files end up in the
source package, something I would expect an uploader to know.
(I hope tag2upload supports Git LFS too. We should allow use of it
where appropriate. But as `git clone` does the right thing for Git LFS
it should be easy to enable if not already done.)
Ansgar
[1]: https://pkg.go.dev/golang.org/x/mod/sumdb/dirhash#Hash1
[2]: For example just include output from an additional `find . -type
f -printf ... | sort` or similar in the hash with the output including
all relevant data.
[3]: Even though an upstream tag doesn't seem technically required,
its presence is enforced by tag2upload for some reason I don't know.
Maybe that could be omitted to make the interface easier to use
manually.
[4]: Often even without downloading the file as long as the same hash
as Git LFS uses is used (currently SHA-256).
Reply to: