On Sat, Apr 01, 2000 at 04:00:20PM +0200, Marcus Brinkmann wrote: > On Sat, Apr 01, 2000 at 12:55:53PM +1000, Anthony Towns wrote: > > But unfortunately that's not quite the choice I have either, since for > > some reason that I can't fathom, people seem to think that a dinstall > > key would be an abomination to man and God and I'd probably be summarily > > kicked out of the project as soon as I tried sending a patch somewhere. > > Or at least it'd never get applied. > It seems you feel personally insulted. Not insulted, just frustrated. > I am sorry for this, but > unfortunately it doesn't change the situation that the signed packages case > adds a further point of weakness to the chain of trust. And this is one of the reasons. It *leaves* a point of weakness in the chain of trust, it doesn't add any. > As dinstall verifies the keys on the packages (which already exist, btw, > they are just not propagated), it puts itself in the middle of the chain: Well, as Jason points out, they are propogated: by the -devel-changes list. They're not very /convenient/, though. I was figuring to make them convenient enough to automate, you'd need to tack them on inside the .deb, like has been proposed in the past. You're welcome to correct this assumption, if you like. > signed packages --> dinstall --> user > 1 2 > > Now link 2. It is currently absent. What you seem to suggest is to add a key > (dinstall-key) here, so the user can verify the archive. This adds a point > of weakness. As the dinstall key can't be used automatically and kept "truly"[1] > secret (it directly depends on the security of master), this weakness is rather > huge. This problem is avoided if the link 1 is propagated to the users: I'm sorry, but that's a matter of opinion. If you're really *hugely* worried about the security of master, then please, show us your scripts that you've already had to write to cope with the fact that master's so insecure it's probably already compromised. Yes, it's a problem, but one you seem to be vastly overrating. > signed packages --> dinstall > \ 1 > \--> user > 1 Really, what we have is: maintainers ---------3---------. | V 1 users | ^ `--------->debian--2-------' The first link is already checked completely. Debian knows that all the packages it distributes are created by developers. Link 2, which could be accurately implemented by signing Packages files and nothing more (and is hence really easy to do, really easy to automate and adds next to no overhead at all), allows a user to confidently say "This distribution is Debian's." Hence, if Debian (ie, all our servers, some of our important people, whatever) gets compromised, they're stuffed, yes. Do think about that though: Debian gets compromised. That's not some J. Random Event that happens every day, every month, or every year. It's not something you can just blithely work around, either. People installing for the first time might be willing to trust www.debian.org to be controlled by Debian, but they're not going to have any other way of verifying the whole debian-keyring. If www.debian.org is compromised, there's no reason for them not to accept some bizarrely wrong keyring as gospel. Link 3, allows you to verify for yourself who built a particular package that Debian distributes. Or at least, allows you to verify the key they used. Verifying that they're an actual person, that they're really someone you have a reason to trust, and that they themselves haven't been compromised, is less trivial. (This is asserted by `Debian', but hey, like you say, Debian could be compromised. Who'd wanna trust them?) > In this situation, I don't have to trust anyone except the Debian developer. > Not the admin team, not the security team, not master, not dinstall. Can't > you see that this is a crucial advantage? Can't you see that it's a crucial *flaw*? You have to trust *every* person who's a developer. And guess what. That means you have to trust the admin team and the security team. It means you have to assume that every machine every developer stores a secret key on is maintained as or more securely than master. > If you also want a link 2 from dinstall to the user, I don't care. But don't > tell the users that link 2 asserts that all packages come from Debian > developers, it doesn't. No, it asserts that all packages come from *Debian*. Debian itself states that they'll only distribute packages that come from developers listed in the keyring; and yes, it might turn out that Debian as an organisation has been compromised, or hacked, or is just lying. Cheers, aj -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds
Attachment:
pgpg10XYoJf2t.pgp
Description: PGP signature