Bastian Blank <wa...@debian.org> writes: > On Tue, Aug 27, 2019 at 05:04:06PM -0700, Russ Allbery wrote:
>> I think this requirement is a bit incomplete, in that I don't >> understand the use case that would lead you to want to do this. It's >> more of a description of an implementation strategy than a use case, >> which makes it hard to find other ways of accomplishing the same use >> case. > We don't want to be forced to trust ftp-master. We have reproducible > builds to verify the content of binary packages. We have the user > signatures to verify source packages. Of course none of this are > foolproof or will work all the time. I get that part. What I'm trying to understand is why. What is the underlying goal that you feel you are accomplishing by being able to independently cryptographically verify the uploader of a *.dsc file? When would we do that independent verification, and why would we do it? I think this bit from earlier in your message may be the answer: > Yes, I did in the past complete security archive checks against > signatures, both on the advisories when they still contained checksums, > and the dsc signatures. So you're using this as a audit and detection strategy to discover whether someone managed to compromise ftp-master in the past without us detecting it? The reason why I'm trying to get at the use case is that we're paying a fairly high technical cost in order to publish cryptographic signatures on the *.dsc file made by the maintainer. As long as this is a requirement, we're blocked from a large number of possible designs that would treat the Git repository as more of a first-class citizen in our development process. This isn't just Ian's tag2upload proposal, but also many other potentially useful designs. Consider, for instance, being able to do automated source NMUs for archive-wide minor source problems the way that we can do binary NMUs to trigger rebuilds. Or suppose that I want a Debian package to be *truly* team-maintained so that any Debian Developer can merge PRs and then, if automated tests pass, the resulting package is automatically uploaded to the archive. I understand that each of these ideas is in itself controversial, and many of them we may never want to do for other reasons, and I'm not saying anyone is going to work on doing these things tomorrow. But I want to dig in a bit on why published cryptographic signatures on the *.dsc files by DDs are so important to you, since I think it blocks an entire branch of solution space. Therefore, looking more deeply at what problem you're trying to solve (independently verifying the signatures isn't itself the problem, it's an implementation strategy for solving some as-yet-unstated problem) is useful because it lets us see whether there's another possible way to solve the same problem or if this really is the best approach (with, to be clear, a bias towards the existing approach because we've already implemented it). > Right now the team delegated to keep the archive running and safe is not > willing to drop the ability to verify the contents independently. What I'm hoping for is an open design discussion where everyone is prepared to have their minds changed. I'm also trying to tease apart the reasons *beneath* the invariants that you're trying to maintain. In any system that's been around for a long time, there are some long-term invariants that turn out to not be as useful as people think they are, and are worth thinking about dropping to allow more design flexibility. I'm not saying that this is definitely one of those, but I think it's worth discussing. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
