On Friday, June 14, 2024 9:23:03 PM EDT Russ Allbery wrote: > 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.
I appreciate that you took the time to do that. I do have some questions that I've been meaning to write down about that, but I keep letting myself get pulled back into this thread. I agree with basically all of that, but let me suggest a different way to look at this. I suspect it may be more of an organizational dynamics problem than a technical problem (to be clear, this is speculation on my part). Within a complex organization (Debian certainly qualifies), maintaining an appropriate alignment between responsibility and authority is both critical and difficult. I don't seem to have a recent FTP delegation message on my computer, but the most recent one I could find includes: > FTP Masters, commonly referred to as "ftpmaster", oversee and maintain > the well-being of Debian's official package repositories. This GR removes part of that authority and moves part of the functionality of DAK (which is also explicitly mentioned in the delegation email) outside of DAK for at least some uploads. Reduction of authority to execute the assigned responsibilities can be a very uncomfortable position to be in. Personally, I have quit roles where authority and responsibility became sufficiently imbalanced. Even if tag2upload has absolutely no negative impact on the overall security of the archive, it makes it more complex for the FTP Masters to execute their delegated responsibilities. I suspect this can be solved, but the solution isn't technical. Scott K
signature.asc
Description: This is a digitally signed message part.
