"S. Alexander Jacobson"
* With GPG, all developers need to create and manage private keys (including all that workflow associated pre-generating revocation certificates, etc). With SSL, only server operators do.
How do server operators know that the packages they get come from the actual developers and are not forged? If you use an SSL upload, how do you know who or where the upload came from? In this scenario, developers must be their own server operators to achieve any security.
* With GPG, developers need to keep their private keys secure on all their machines. If ANY of their machines are cracked, their identity is owned until they are able to publish a revocation certificate. They need to keep all their revocation certificates in a safe place and NOT on the machine where they keep their private keys and proximate to wherever they happen to be! Developers have to be really diligent. With SSL, only server operators need to manage certs and they are already expected to be diligent.
No, this is not true. Keys are kept on a single machine. Your identity is not 'owned' if a copy of your keyring is stolen, not unless that keyring has no password. You will want to keep the revocation certificate in one or two other places, so there's a greater chance that someone would crack your box and then revoke your key. On the other hand, SSL certificates must have no password, or else they require the server admin to type in the password each time the SSL server starts. In the password case, you either need to decrease security by sharing the password with multiple people or you need to wake up the guy with the password everytime the power goes out, the kernel panics, or other force majeure restarts the SSL server or the hardware. If someone cracks the SSL server, how do you revoke the certificate?
* With GPG, developers needs to establish a chain of key signings to all of the users of the modules they create. With SSL, developers only need a relationship with a server operator.
No, this is not true. There is no difference between a relationship with a server operator and a chain of key signings.
* With GPG, module users have to understand the whole public key security model and how to use gpg etc (e.g. how do they get a key signing relationship? how often will they do a gpg --refresh, why?). With SSL, users don't need to learn anything new.
SSL doesn't do what GPG does. SSL doesn't have any way to update certificate trust other than manually removing or adding certificates.
And this isn't all just theory. In practice, SSL's transport security model has been *vastly* more successful in the real world than any content signing model (e.g. whatever happenned to SHTTP(1)). And note that the *only* widespread code-signing model, is Microsoft's active-x and that relies on a centralized CA, like SSL, rather than a GPG style web-of-trust.
No, this is not true. Other widespread code-signing models exist in the form of Linux distributions that allow signed packages that fit into the web of trust, see Mandriva, Red Hat, and Debian for examples. If you want to take Microsoft as an example, they also use GPG-style per-file signatures for ActiveX components. They don't use SSL in place of the per-file signatures. -- It seems I've been living two lives. One life is a self-employed web developer In the other life, I'm shapr, functional programmer. | www.ScannedInAvian.com One of these lives has futures (and subcontinuations!)| --Shae Matijs Erisson