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