hackage, cabal-get, and security

[S. Alexander Jacobson]

On Wed, 18 May 2005, Isaac Jones wrote:
>> i don't love to debate, but creating CPAN-like packages library is
>> one of key steps to rising language popularity. and i definitely want
>> that entrance ticket to this library will cost less than $50 ;)

To be clear Hackage and SearchPath serve different functions.  Hackage 
provides a directory of already implemented functionality that 
developers may want to use.  SearchPath is designed to make it as easy 
as possible actually to use it.  I hope hackage will evolve into 
something like CPAN.  SearchPath is intended to be a way to automate 
the download and installation of third party modules/packages used in 
your code.  It is intended as a superior alternative to the explicit 
use of -package on the command line.

> I tried to make clear that Alexander Jacobson's SSL proposal is
> completely different from the Hackage security proposal.
> The hackage security proposal doesn't cost any money.

And, to be even more clear, what we are talking about here is the 
merit of using the GPG security model in Hackage as opposed to SSL.
Either/both are in theory compatible with both Hackage and SearchPath.

And neither security model costs any money for module/package users.

However, since both require someone to operate servers that host 
directories and packages/modules available for download, both impose 
some cost on module/package authors/devlopers.  SSL adds ~$4 per month 
to the cost of operating a set of physical servers.  But since 
multiple physical servers may share the same cert and since large 
numbers of developers may share the same virtual server, the actual 
marginal cost of SSL is effectively nothing.  As a data point, 
Huricane Electic charges $10/month for basic shared web hosting 
whether you use ssl or not.

The big issue is that the GPG security model imposes a huge amount of 
additional complexity on both users and authors/developers.

* With GPG, all developers need to create and manage private keys 
(including all that workflow assoociated pre-generating revocation 
certificates, etc).  With SSL, only server operators do.

* With GPG, developers need to do this on ALL the machines from which 
they may publish.  If they suddenly find themselves on a new machine, 
they have no way to do this unless they ALSO have shell/remote-control 
access to a machine on which they maintain a private key.  Access to 
the file system is not enough!  With SSL, only live servers need 
private keys.

* With GPG, developers need to keep their private keys secure on all 
their machines.  If ANY of their machines are hacked, 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.

* With GPG, developers needs to establish a chain of key signings to 
all of the users of the modules they create e.g. Bulat's example that 
he has no relationship with Simon so Simon can't use his libs.  Note 
that Bulat probably does not plan to go to any "key signing parties" 
any time soon.  With SSL, developers only need a relationship with a 
server operator.

* 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.

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.

-Alex-

1. http://www.homeport.org/~adam/shttp.html

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com