Scott Kitterman <deb...@kitterman.com> writes: > Maybe. Maybe this breaks the thing into two parts in a way it wasn't > before If you verify the signature on the source package and the key is > in the keyring, you know that the package was uploaded by someone > authorized to do so and that the code you have is what they signed. > With tag2upload you have neither. You have tag2upload's claim of who > signed the tag and the source package constructed by tag2upload. The > connection to what the uploader intended to upload is completely > indirect.
I guess I consider separating authentication from authorization to be a pretty routine thing to do, since I've worked on lots of systems that do that. But yes, it is a change from dak's perspective in that it is no longer the sole agent involved in authentication checks and it has to trust that tag2upload did its part correctly. > I don't think there's any real mystery about this, but the claim in the > draft GR was that there was an unwillingness to communicate. I cannot speak for the authors of the draft GR, but the claim that I would make is that there seems to be a lot of reluctance on the part of the FTP team to communicate *why* they think that trusting tag2upload is a problem. My conversation with Ansgar felt typical to me: vague assertions of security problems without an explanation of what those assertions are based on. Again, this is their perogative under the Debian constitution, although it has reached a point that I personally find a bit rude. But the project can decide how much weight to put on those assertions. With any luck, there's an explanation already waiting in my inbox while I'm writing this and I'll be happily wrong. :) I guess my assumption is that the security objections are based on a gut feeling or vibes, which makes them hard to explain. That's a real thing, and I am familiar with the feeling, but I also don't expect it to be that persuasive to other people. When it comes down to rejecting substantial amounts of work that other people have put into solving a problem they care deeply about, I feel like it's my responsibility to really dig in and figure out what my vibes are based on or to let go of my objection. That's my personal take; obviously other people can have their own opinions on that score. If the objection is that there should be one and only one piece of software that verifies package upload signatures, meh, sure, all other things being equal it's better to only have to trust one system than two, but the whole point is that all other things aren't equal. Additional complexity is always a drawback, but it's also often the cost of adding new features. If that's the sole objection, it seems pretty weak to me. If the objection is that the implementation of the tag2upload security checks is not secure, then that is a very real problem that would need to be fixed and someone should spit out the details so that we can have a real discussion. But I have a hard time imagining that this is a blocking architectural objection. It's clearly possible to securely verify a Git tag signature, modulo concerns about SHA-1 hashes that have been discussed exhaustively elsewhere. If tag2upload is doing it wrong, then tag2upload can be fixed. But this is all speculation on my part. I don't actually know what the objection is because no one has explained it, at least that I have seen and understood. Maybe I just missed it. > Some or all of them may be unwilling to continue to be responsible for > managing the security of the archive once the security of the system has > been (in what I believe to be their view) compromised. You narrowly dodged me going off on a long rant about one of my pet peeves about the computer security profession, but I had a nice dinner with my family and decided to spare everyone. :) I guess the main thing that I will say to this is that I certainly hope people are not feeling this way because I think that would be an unhealthy way to approach a dispute. I guess this gets into personal philosophy, but I think it's important to not hold one's positions so tightly that they become brittle. I find that when I do that, *I* become brittle, and it's a deeply unpleasant experience. It's not very helpful to think of systems as secure or insecure. Security is always and forever a tradeoff. This is particularly true of the sort of discussion where we're having, where no one is identifying a concrete attack that could be performed against tag2upload today. Instead, we're discussing design principles that may or may not make tag2upload vulnerable to problems in the future. Those discussions are very important -- my security review was full of them -- but they're also inherently speculation and opinion, and it's always possible that one's design intuition is wrong. One of the reasons why I wanted to write a proper security review and post it publicly is because I want people to check my work. If someone finds a serious problem that I didn't think of, I would hope that I would change my opinion accordingly. I know that's psychologically difficult to do once I've publicly committed to a position, but that's all the more reason to constantly restate to myself the importance of holding opinions loosely and being open to new information. This should be a collaborative process. The goal is to enable people to do the work they want to do in a reasonably secure fashion, not to stand in front of people and declaim "you are secure" or "you are not secure." I have not done a review of the implementation. I'm not a great code reviewer becuase I have a lot of difficulty separating my aesthetic preferences from my analysis. I'm better at architecture. If someone is willing to do a detailed security review of the code, that, as far as I'm concerned, would be great. That's how we get better. If that turns up problems, clearly those problems should be fixed. I am absolutely confident that if someone discovers an exploitable vulnerability in tag2upload, the tag2upload developers would be the very first people to turn the service off until they can figure out how to fix the vulnerability. Everyone involved in this discussion cares deeply about not compromising the security of the archive. At the end of the day, it's just code. Most code problems are fixable. We're pretty good at what we do. I have great confidence in Debian's ability to make tag2upload work in a secure manner if we decide that's something we want to do. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
