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

On Wed, 18 May 2005, Isaac Jones wrote:

Also, Hackage is coupled with a tool called cabal-get which actually does the installation onto the end-user's machine, so his characterization of Hackage as simply a package database is also incorrect (HackageDB is the database part.)

Perhaps, I wasn't clear. To me the most valuable thing about Hackage is that it provides a directory of already implemented functionality that developers may want to use. I was silent about cabal-get because I don't think users who are not building packages should ever have to worry about dealing with package names. SearchPath is intended to eventually abstract out the whole notion of package names. It looks at all the imported module in the modules you are passing to GHC, finds implementations for them on the Internet and downloads/installs them if necessary all without the user having even to think about package names. Note: right now it handles darcs/svn repositories but not packages. I hope to add package functionality soon (perhaps using cabal-get for implemenation!)

His assertion that no one uses codesigning is also incorrect. Is used very successfully in the Debian GNU/Linux system for a nearly identical problem. Debian is renowned for its packaging solutions.

Actually, the Debian model maps more closely to signing module maps than it does to signing packages. Or more particularly, Debian provides you with no help in validating any package not part of a release. Moreover, as I noted in my prior message, the Debian model is particularly irrelevant to the operation of Hackage's role in reliably mapping package names to URLs.

The difficulties with using GPG can be simplified by writing wrapper tools. That has been the plan all along.

That doesn't change the fact that it forces users to attend key-signing parties. Note that Debian in fact relies on key signing parties.

I hope by now people learn to take Alex's bold assertions with a grain of salt. I wouldn't keep following up to these emails except that folks keep asking me personally if he's right. I don't know if I have time to continue pointing out exactly where his mis-characterizations lie, but I hope that doesn't mean that he will take away our mindshare by speaking untruths about our tools.

Isaac, I thought the goal here was to improve things for the Haskell community not to build midnshare for a set of tools. Personally, I hope that Hackage succeeds and does for Haskell what CPAN does for Perl. Getting all defensive about "our tools" is just unhelpful. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

Abstracts: GPG secures documents, not interactions. SSL secures interactions, not documents Hackage is an interaction not a document. Therefore, SSL can secure Hackage, but GPG can't. GPG requires that users learn GPG and attend key signing parties. SSL requires no additional work from the user. Therefore, SSL is easier for users than GPG. GPG requires authors to learn GPG and attend key signing parties. SSL requires authors to learn nothing. Therefore, SSL is easier for authors. SSL requires server operators to obtain a cert and authenticate users. GPG requires little of server operators. Therefore, GPG is easier for server operators. GPG requires that an arbitrarily long chain of attendees at key signing parties all to manage keys AND verify identity properly in order to authenticate authorship of a document. SSL requires only that a server operators manage keys and verify identity properly in orer to authenticate authorship of a document. Therefore, SSL is less risky/more secure than GPG. Gory Details: A Hackage installation exists because some server operator did the due dilligence of building up an accurate package database. However, since Hackage exposes a search interface rather than a database file, absent a secure (SSL) connection to the server, Hackage users have no way to authenticate search results e.g a mapping from package name to URL. On Thu, 19 May 2005, Shae Matijs Erisson wrote:

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.

Typically server operators issue developers a password via some secure means. The server operator knows it is the developer that is uploading because only the developer (hopefully) has the password, just as with GPG only the developer (hopefuly) has the private key. I'm not sure what security you think developers need here.

...

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

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.

No. You need a key on every machine on which you intend to sign code. The worry is not just that someone will steal your keyring file. The worry is that they replace your GPG executable with one that allows them to intercept your password. And my point about revocation certificates is that you are vulnerable to anyone in your network that fails to handle maintaining revocation certs properly. I think server operators are likely to be more reachable and diligent about such things than work-a-day developers. And the SSL/CA model doesn't require that a user maintain a revocation cert in order to accomplish a revocation!

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.

However, if someone gets root, they can do whatever they want anyway so, ALSO getting the private key may add little value. Moreover, since they can replace the password system and force a reboot in any case, there is no major value to requiring a password. Note, they can only do damage for the time they have root and are not discovered. Note that usually professionally managed SSL servers are more hardenned than the typical developer box.

If someone cracks the SSL server, how do you revoke the certificate?

You tell your CA to add it to a Certificate Revocation List.

There is no difference between a relationship with a server operator and a chain of key signings.

Actually there is a substantial difference. Both sender and reciever have a very specific relationship with a CA whose job it is to provide these sorts of relationships. One requires you to go to key signing parties. The other does not. In theory you can implement a CA type role on top of GPG, but then you are operating a CA rather than a GPG chain of trust.

...

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

SSL doesn't *need* a way to update certificates except when you want to add/remove a CA and that is/should-be relatively rare. GPG requires users to deal with manual key exchanges on a regular basis.

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.

With Debian, I assume you are referring to http://www.debian.org/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign It looks like they are experimenting with signing packages and it looks like they are still not clear on exactly what a signed package actually signifies. Note this is in contrast to signed release files which would be analogous to signed modulemaps rather than signed packages. In theory I could implement that sort of security for module maps, but that is a different discusion.

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.

True. Except that note that Microsoft code signing is CA based NOT GPG-style chain-of-trust based. And the reasons they chose code-signing over SSL for ActiveX are not necessarily relevant here. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

"S. Alexander Jacobson" writes:

Abstract:

GPG and SSL are tools for entirely different goals. GPG can give you some assurance that a file was signed by a certain person. SSL can give you some assurance that received data is the same as server data.

SSL does not guarantee that a certain person put information on the server, only that the information that you got did come from the server. That's just not the same thing at all.

You can skip the rest of this message if you don't want the blow by blow.

...

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

...

* 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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

I'm no expert on any of this, but from the descriptions given so far on this mailing list, I think you have oversimplified the differences here.

GPG secures documents, not interactions. SSL secures interactions, not documents

Yes.

Hackage is an interaction not a document.

Hackage is an interaction /over/ documents.

Therefore, SSL can secure Hackage, but GPG can't.

Wrong. SSL can secure the transport layer of document transmission, but does nothing towards authenticating the documents themselves. Garbage is still garbage, even if it is sent securely. GPG authenticates the documents, which means it does not matter whether the transport layer is secure or not - I can still be sure the document is uncompromised.

GPG requires authors to learn GPG and attend key signing parties. SSL requires authors to learn nothing. Therefore, SSL is easier for authors.

Provided the author doesn't mind an attacker replacing their package with a compromised one, with no immediate means of detection, and no easy way to alert users when the intrusion is detected. Regards, Malcolm

I've read the book. I understand crypto well enough. Perhaps you could answer a simple question: If I query Hackage for a package URL, what assurance do I have that the URL I receive is actually correct? Note, I am NOT asking how you authenticate the content retrieved from that URL. I am asking how you know the URL itself is correct? -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Thu, 19 May 2005, Shae Matijs Erisson wrote:

"S. Alexander Jacobson" writes:

...

GPG secures documents, not interactions. SSL secures interactions, not documents Hackage is an interaction not a document. Therefore, SSL can secure Hackage, but GPG can't.

I suggest you read Bruce Schneier's book Applied Cryptography. I hope that will unconfuse you. For more information on the book - http://schneier.com/book-applied.html It's an excellent book, I read it when I had a job implementing RFC3161. -- 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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Ok, then the question becomes How do you authenticate the content unless you know its key? -or- How do you know the key you should use to authenticate the content? -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Thu, 19 May 2005, John Meacham wrote:

On Thu, May 19, 2005 at 12:27:51PM -0400, S. Alexander Jacobson wrote:

...

I've read the book. I understand crypto well enough. Perhaps you could answer a simple question:

If I query Hackage for a package URL, what assurance do I have that the URL I receive is actually correct?

Note, I am NOT asking how you authenticate the content retrieved from that URL. I am asking how you know the URL itself is correct?

Because if the URL is not correct, then the content will not authenticate. I am not sure how else to put it since that is what is important, that you get the package you are asking for. Note that this does not require you trust the hackage server at all, all security is end-to-end as it should be. There is no need to trust any link in the chain. hackage is meerly a way to match providers of packages to consumers of them.

So, A better question is, if the content authenticates, does it matter whether the URL was correct? At worst it means somone is clandestinly mirroring your content, which doesn't seem that bad :)

SSL authenticates the server and secures data on the wire against tampering. However, we want to authenticate the _author_ of packages, not the hackage server and securing data on the wire is a non-issue since all data is gpg signed. The hackage server is not special, the authors are the primaries and the hackage sever is just a convienient meeting place and an ad hoc (but not special or mandatory) namespace management center for packages.

There is a place for SSL, and that is if hackage allows any sort of password based modification of content via web forms. But for the basic functionality of storing and serving packages, it is not needed.

John

-- John Meacham - ⑆repetae.net⑆john⑈ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries