hackage, cabal-get, and security
S. Alexander Jacobson
alex at alexjacobson.com
Wed May 18 18:41:28 EDT 2005
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
* 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
* 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
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
More information about the Libraries