HW42 writes ("Re: Security review of tag2upload"):
> Is this really common practice that Debian uploaders sign (source)
> packages they built on less-trusted systems?Like Russ, I don't really know how common this is. I do know this: people asked for, and I implemented, a special mode with dgit, called `dgit rpush`, which allows you to have your signing key on a different system to the one with the source code, source package clean target, dpkg-source, etc. That enables that same workflow. (I did this because I want people to be able to use dgit without changing other aspects of their workflows.) But it might be worth stepping back a bit and seeing *why* people might want to work this way. The reason is probably that the source package build is complicated and inconvenient. You'll need the source package tarballs, which may be large. In pre-dgit workflows you typically have to run the package clean target, so you must have its build dependencies installed, so perhaps it's a chroot. If you're doing a with-binaries upload, it can be convenient to do all the building parts on the same machine. I wouldn't be surprised if some people use porterboxes for this. It's even possible that some maintainers' main systems aren't Debian derivatives, so they don't conveniently have Debian source package tools. Some of these use cases could be replaced with tag2upload, especially if we can widen acceptance of source-only uploads. So perhaps we could hope that fewer maintainers will want to work this way. (Perhaps, even if the problem was the source code size. git is much better at cacheing and incremental updates, than source packages - updating a git tree, and pushing a tag, are a lot cheaper than transferring new tarballs in both directions.) Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
