No GPG thanks

How do you propose to authenticate uploads? By giving people a password on the upload machine, so that anyone who cracks it can load malware on all Debian users’ machines and not be traced?

If you don’t like GPG, propose a realistic alternative. If you think that the web of trust is daft, please explain why; I suspect that you don’t understand it.

Contributions can be rolled back, like a Wiki if someone uploads malware.

Time delay like what already happens with Unstable->Testing->Stable can make sure people notice any malware uploads.

The Web of trust is broken on so many levels. I dispute trust elements when you just meet someone and see their ID card. I dispute the “Web” where other people make that decision for me.

The technology itself is braindead. How many people keep their GPG key on a networked machine? More than most would like to admit.

The alternative is Wiki like contributions.

im not sure what you mean with “wiki like contributions”. Wiki like contributions the way
i know them, do not ensure at all a certain person ist trustworthy. This is by far more
worse than how the current system works.

Also, the web of trust does not mean to tell you which person you have to trust or not, its
still your decision.

This isn’t called for, at all. Unless you can show me a way in which an attacker can abuse a compromised web of trust to upload trojaned binaries.

Do remember that the DAM will never replace a key without checking, and without double-checking.

Hmm. I have read this blog post as a satirical commet WRT the (maybe overrated) response to Martin’s blog post. But here seem to be people that take this serious, as http://blog.technologeek.org/2006/05/26/26 seems to do…

Please tell us that it was ironical, Natailan…

Wouter: If a DD’s secret key is compromised, the attacker can upload.

abi: Wikipedia does just fine with its permissive contribution system. Once a DD key is accepted into the keyring, its not your decision if you trust that DD or not, is it?

hendry: You seem to be arguing in two opposite directions. On the one hand you worry that if a DD’s secret key is compromised, the attacker can upload packages. On the other hand you seem to advocate anyone and everyone having equal ability to upload? I’m confused?

AFAICS, mapping PGP keys to identities (the purpose of the web of trust, keysigning parties, etc.) isn’t the most important thing about Debian’s use of PGP. The important thing is that the responsibility (and hence credit or blame) for contributions is traceable (at worst, if someone gets into the web of trust using fake ID, it’s consistently-pseudonymous, like a wiki where all users must register).

If I sign someone’s key at a KSP, it means something like “I believe the holder of key 0×12345678 is in fact Fred J. Foobar”. This is somewhat important to know for Debian’s purposes, but not the most important thing. For Debian the most important facts are “the holder of key 0×12345678 is the DD with login foobar, who got through NM on such-and-such a date and is trusted to upload packages”, and “these packages were approved by the holder of key 0×12345678”.

Since signed packages mean that an attacker can’t upload packages which appear to be from someone else, it’s possible to use a contributor’s reputation and previous behaviour as a guide to whether they are likely to do something harmful or malicious in future (presumably, by the time they become a DD, the answer is “no”). If packages weren’t signed, you’d have to assume each new package was uploaded by an imposter and there’d be no (reliable) way to use any sort of reputation.

Also, because a DD (or other free software contributor) builds up a reputation which is tied to their PGP key, they have an incentive to avoid it getting compromised, and to avoid doing stupid or harmful things in packages they signed. If some malware turns up in the Debian archive with Fred Foobar’s signature on it, there goes the good reputation he’s been building up; even if he can exploit flaws in the web of trust (e.g. obtaining some fake ID) to convince people to sign his newly generated key, 0×87654321, under the name Bob Barfoo, he’ll have to start building a reputation again from scratch (e.g. going through NM again, which I hear takes quite a while

Since sooner or later a DD’s secret key will be compromised. Would blaming that DD be fair?

What I mean by anyone being able to upload is the same way (almost) anyone is allowed to contribute on Wikipedia. People can build up a “reputation” with the Wiki ID they’ve created. I guess they could continue using (untrusted) GPG to associate their uploads with their Wiki ID/account. But that’s not important.

What’s important is that contributions are checked much in the same way Wikipedia’s are. Diffed against the previous upload. Searched. Checked again. And then it goes off for a build.

Yes, it would be fair to blame the DD if he did not protect the key properly. If you cannot protect your secret key properly or are unwilling to deal with the consequences of a failure, stick to being sponsored and don’t become a DD.

In fact, if someone steals a key from a DD, and he doesn’t notice it and revoke the key before it is missused, I fully expect him to bear the full consequences of it: clean up after the entire mess made with the key at personal cost, helping audit all changes done with the key (so that we can find which were rogue, which were made by him), bearing the brunt of the complains about any damage done with they key in the public, etc.

Note that secret keys of DDs have been reported by their owners to have been “stolen” in the past. Somone else potentially gained access to the keys, even if only for a short time window, and only the passphrase hold them back from using the keys they might have copied. It doesn’t matter if someone actually got to the keys or not, if there was a chance they might have, you revoke the key.

This means your key passphase better be very good, and very strong: it is all which holds an attacker at bay if he got access to the key… and thus it means you have to be very paranoid where you type it, and how strong it is against dictionary and brute-force attacks. If it bothers you to have long passphrases with gibberish on them, either get a smartcard that does the gpg crypto inside itself, or don’t become a DD.

Heck, I wish someone would donate 1100 such smartcards and readers to Debian (or make them cheap enough to get), so that we could make using them a requirement for DDs.

Keys being stolen are expected (as a rare event), and unless the DD made a gross error in handling the issue (like not noticing that the key could have been compromised soon enough, not revoking the key immediately by uploading the revoked key to Debian’s and public keyservers, and not notifying Debian ASAP about the compromise), there is no expected consequence other than the fact that he has to go through the key replacement procedure (which can take some time), and help verify whether the key was used outside of his control.

So far, no stolen gpg key has ever been used to access Debian services like uploading or voting [that we know of].

The issue here is that you show a surprisingly naive attitude about the whole deal. I sure hope you are not going through NM…

A key (when properly handled) is much more secure than a simple passphrase (even when the passphrase is also properly handed). This is the very basic security concept of requiring “something you know” and “something you have”, against just requiring “something you know”.

The whole Wiki idea is either moot (you would use passphrase-protected keys to auth to the wiki, at which point you have exactly what Debian has right now, with a different interface), or just plain stupid from a security standpoint.

Digital signatures last after the upload. A simple login in some wiki, doesn’t. And digital signatures are extremely more difficult to tamper with than a server log, and much easier to distribute (which BTW, Debian does. We send all of them to mailing-lists that a number of people around the world read and archive). They could be very helpful when tracking down compromises.

And the acceptable time-window for a compromised package in Debian is very close to zero. I doubt very much so it is the same for a bogus Wikipedia page.