Hi and thanks for quick reply, > > As you know I have been testing dgit and reviewing tag2upload, and to > > my understanding tag2upload will generate the *.orig.tar.gz tarballs > > using dgit > > (Using 'git deborig', not dgit.)
Right, it is a separate tool in devscripts (https://manpages.debian.org/testing/devscripts/git-deborig.1.en.html). However you wrote it for dgit and the custom workflow where you advocate merging from upstream instead more traditional way of keeping Debian patches clearly separated from upstream by having debian/patches directory inside of version control. > tag2upload properly archives upstream signatures on upstream git release > *tags*, which is an improvement on what we have now, for modern > upstreams. > > You are correct that detached signatures on tarballs aren't uploadable. > Packages with upstreams where this is more important shouldn't use > tag2upload. And by "aren't uploadable" you mean this is how you designed it and chose to not use signatures, not that doing it would inherently would be impossible. Would it by any chance be possible to extend "git deborig" to check whether debian/upstream/signing-key.* exists, and if so, generate the tarball using pristine-tar and keep the supply chain intact? Would you accept patches that implement it? I know tarballs are falling out of fashion and git tags are the future - and I also advocate signing tags - but there are a bunch of big and important projects that don't have a 1:1 mapping of git contents to what they actually intend to go into Linux distros. For example various test code / test data might be intentionally omitted from the tarball, or for example documentation added into the tarball. Also not all upstreams use git, and the in Debian the git exists only because the maintainer created if for the sake of being able to manage the packaging. Then there is also the fact that git hasn't migrated away from SHA1 fully yet, while the tarball signatures can today be actually cryptographically secure. Considering git-buildpackage has all of this already sorted out and it works nicely, and gbp being able to even do dual git+tarball imports to show the full audit trail, it is not possible to do in any way. Having such supply chain security covered by tag2upload is just a bunch of implementation work, right? > In general: I am not willing to spend time retreading the grounds of the > disagreement now. I want to work on the programming work to enable this > new feature, instead. Please see the debian-vote archives at the time, > if you really want to know. Thanks for the pointer - indeed there was a thread with hundreds of messages, checking it now. I just want to re-iterate that I like the idea of having DD signed git tags trigger uploads to Debian. It has many benefits in quality and security. I just wish we could get it without taking steps backward on security aspects.
