On 28/07/2019 20:01, Sean Whitton wrote:
When I read your first e-mail what I thought you had in mind was just this -- having git-debpush compute a stronger hash of the tree object and add that to the tag metadata, ignoring commit objects.
Of the files in the signer's repository, not of an actual tree object (since the second is a list of file/subtree SHA-1 hashes).
But now I'm struggling to understand the relevance of your discussion of having git-debpush create a .dsc in your second e-mail, if what you're actually talking about is hashing a git tree object.
"Tag with sha256" and "hidden .dsc" are two alternative options: the first is a narrowly targeted fix for the SHA-1 issue, the second a bigger redesign.
(As an aside, if what you want is to hide .dsc creation from the user but still do it on their machine and upload it, `dgit push-source` is already available.)
That doesn't push to salsa [0]. However, I agree that it otherwise does solve the problem of "not making the uploader think about how Debian source packages work", without requiring a server-side component.
This does still "waste" the uploader's bandwidth on tarballs, but I don't know if that's an issue in practice. For most packages [1] it is a much smaller data volume than the downloads needed to keep an up-to-date sid for building/testing the package.
[0] https://sources.debian.org/src/dgit/9.6/dgit-maint-gbp.7.pod/#L117[1] Rough numbers: ~80% of .orig.tar.*z are <1MB, ~97% <10MB; a gcc update is a ~30MB download.