Ansgar 🙀 <ans...@43-1.org> writes: > On Tue, 2024-06-18 at 18:25 -0700, Russ Allbery wrote:
>> 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]. I'm not sure I understand: what directory tree do you want hashed? The part that's a blocker for tag2upload goals is any requirement for a hash over the final contents of the source package, because the final contents of the source package aren't known when the Git tag is made. So if the directory over which you would like a hash is the directory that would end up in debian.tar.[xg]z, this design still has that same problem. If it's a hash over the HEAD of the Git tree, which will not match the final source package contents in the general case, I'm not sure I understand the purpose. If you want the HEAD, tag2upload could just give you a Git bundle of whatever depth you would like and then you'd have all the actual data. But I'm not sure that this gives you what you want. > 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. No, the uploader doesn't know this. Some of the files (the ones in debian/patches) are synthesized from Git commits and do not exist at all in the checkout of the Git tree, which will often be in patches-applied form. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
