Bulat Ziganshin writes:

Hello Isaac,

Tuesday, May 10, 2005, 9:21:15 PM, you wrote:

IJ> I'm working with Lemmih on the designs for Hackage and Cabal-Get. IJ> He's a real trooper, since I'm a total "customer" and have hardly IJ> written a line of code for these tools, but keep coming up with new IJ> requirements.

how about taking Perl's CPAN and Ruby's Yaraa for a model?

We have, to some extent, and also Debian's model. (snip)

IJ> This actually already works :)

i think, that many packages authors will prefer to hold archives on their own sites. and imho hackage must provide ability to just send description (package.cabal) to main site, in this case this file must include exact url to download full package. also .cabal file must include "home page" of package and email address of author

This is already actually implemented, but disabled. I think it's best to keep the packages on the Hackage site, at least at first, that way we can guarentee that they will be available, (especially for package dependencies), that the packager hasn't altered them without altering the verison number (requiring rebuilds of other packages), stuff like that. Cabal already has the fields that you are asking for. We'll see how people use things and update our ideas accordingly. Also, the client can work with multiple servers.

IJ> The big problem actually is that this is in no way secure, and just IJ> begging to be exploited. Boo.

imho best way to deal with this problem is "reserving" package names with password. after that, to change any information belonging to package, password must be supplied

So we're basically "reserving" package names with keys instead of passwords.

IJ> 1) Generate a gnupg key. preferably get it signed by someone in my web IJ> of trust (I'll try to organize a keysigning party at ICFP).

yes, yes, we can also use our personal FBI numbers. anyway, someone not working in FBI can't be a good Haskeller :)

Are you saying that crypto-signing is overkill? If so, I would have to disagree, since many people will want to install packages as root. I personally don't want to ask people to trust the good will of the entire internet. peace, isaac

Malcolm Wallace writes:

Isaac Jones writes:

...

1) Generate a gnupg key. 2) use cabal-put to sign and upload a package 3) cabal-get can then be used to download and install as before, but first it checks the signatures of all the packages.

What do folks think of that?

Personally, I think it sounds good.

Cool.

Security is becoming ever more important, and the Haskell community is growing, thereby increasing the currently remote possibility of deliberate malware. Since installation via hackage will be both automatic, and often performed with root access, it is essential to have a good security model from the beginning.

Exactly :)

Having said all that, I don't know the first thing about gnupg, or how to go about signing keys or anything like that. I imagine that for people in remote locations, bootstrapping into the web of trust might be significantly more of a barrier than they would like.

Since we will actually accept packages without signatures, I think this isn't too bad of a problem. Users will get a warning if the key is untrusted, and asked if they want to continue. Hopefully this will present enough of a barrier for script-kiddies and an incentive for packagers to get their keys signed. Maybe the client should even reject untrusted packages and the end user would have to go and twiddle some configuration somewhere to even get the option to override it, that would encourage people to get their keys signed even more :) Is that too harsh? Occasionally we may have a problem with getting people into the keyring, but assuming we can bootstrap from Debian's well-established web of trust, this shouldn't be too bad. peace, isaac

Bulat Ziganshin writes:

Hello Isaac,

Wednesday, May 11, 2005, 7:37:07 PM, you wrote:

...

...

Security is becoming ever more important, and the Haskell community is growing, thereby increasing the currently remote possibility of deliberate malware. Since installation via hackage will be both automatic, and often performed with root access, it is essential to have a good security model from the beginning.

i suggest some compromise variant: signing packages with gnupg, and including all the necessary functionality in the hackage itself. hackage must be able to generate key and to automatically sign uploaded packages - so this will not require additional skills from package writer as currently don't require from package's users

not every package writer are want and able to master another complex program - in this case, gnupg. and if Haskell popularity will grow, percent of such people among all package writers will grow. look at me as example :)

I hope that cabal-put will cover details of how to use gnupg. It's not terribly hard to do the few things that cabal-put needs, but I hope it can automate them. Hackage will also sign the packages, but that's another part of the chain, and not sufficient. Packagers also have to sign their own packages.

so, i think, that attention must be moved to easying of generating keys and autosigning uploaded packages. if this will be impossible, then we must use, i think, at least simple password scheme for uploading unsigned packages. in any way, hackage server must ensure that packages are not overwitten by non-authors

I agree. peace, isaac

My solution in SearchPath (released yesterday) is to rely on a combination of HTTPS and links. The user selects module directories that they trust. They access that directory via HTTPS. The module directory maps module names to package/module URLs. The user can decide that they only want to retrieve via HTTPS. This is effectively a web of trust model, but the only key management needed is getting an SSL cert from a CA like Verisign or Thawte. The open question here is whether it is easier to convince people to serve modules via HTTPS web servers or whether they prefer gnupg key management. A reason to believe that the former will be preferable to the later is that people can easily delegate SSL hosting to others. Delegating gnupg key management is non-trivial. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Mon, 16 May 2005, Isaac Jones wrote:

At the request of Dominic Steinitz, I'll outline the threats that I think this proposal protects against.

The signing of packages prevents a number of attacks between the packager and the server:

1) Accidentally or purposely hijacking a package that is signed by (belongs to) someone else.

2) Uploading a malicious package to replace someone else's good package.

3) Man-in-the-middle attcks between the packager and Hackage.

Checking signatures on the client side prevents:

1) Man-in-the-middle attcks between hackage and the client

2) Automatic installation of anonymous malicious packages

Building a trusted network of keys prevents:

1) Someone creating a key pretending to be someone else

2) Unchecked anonymous uploads (running arbitrary code from an unknown source)

One question that comes up is: how does the so-called "web of trust" help out with this situation? The signing of keys ties the identity of an individual (via their state-issued identification) to a particular key. Now if someone attempts one of the above attacks, after being "trusted" we know who they are in real life. So it's not really a "web of trust" but more like a "web of identity". We will need to put procedures in place for handling a variety of situations, like loss of trust, etc.

This proposal doesn't cover all of that, but it puts a bit of structure into place to raise the bar for an attacker sufficiently high in my opinion, and gives the end-users the tools they need to be as paranoid as they care to be.

peace,

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

Isaac Jones writes:

How does one generate a signed SSL certificate? It's very costly, isn't it?

It's free to generate a self-signed certificate, but that doesn't help much. As you suggest later in this email, there could be a CA on haskell.org.

...

The open question here is whether it is easier to convince people to serve modules via HTTPS web servers or whether they prefer gnupg key management. A reason to believe that the former will be preferable to the later is that people can easily delegate SSL hosting to others. Delegating gnupg key management is non-trivial.

Having used both, my opinion is that GPG is less difficult than SSL. Key management with GPG is globally delegated. It may not be trivial, but my first SSL certificate was definitely more trouble. Here's a short gpg howto for Linux that assumes you have gpg installed: gpg --gen-key creates a new key. gpg --list-keys <yourname> shows you the created key. Choose a keyserver, I use "keyserver keyserver.kjsl.com" in ~/.gnupg/options or add --keyserver some.host.name to the gpg command. gpg --send-keys <yourname> uploads your key to the keyserver. gpg -b --sign filename creates filename.sig, a detached signature for the file. Now to test it on real files: gpg --recv-keys 40620E18 grabs my key from the keyserver wget http://www.scannedinavian.org/~shae/qc-tdd.{tgz,tgz.sig} grabs a file and signature I created. gpg --verify qc-tdd.tgz.sig checks a detached signature against the key and qc-tdd.tgz file. If you check the signature before you have the key, you'll see the key 'nickname' and you can use that as a parameter to --recv-keys 40620E18 is the short name for my key, as shown above. You'll also get warnings if my key isn't already in your web of trust. For related information see: http://pgp.mit.edu/ http://people.debian.org/~weasel/weboftrust/ - Debian's web of trust http://pki-page.org/#PGP - lots of PGP links

I wanted hackage to have a pretty secure chain between the packager and the end-user, without the need for outside sysadmins, outside CAs, or outside methods for moving the package to the web server.

I'd prefer this also.

The "web of identity / trust" would be much better if we had an official central authority like a CA, though, rather than an ad-hoc one.

I don't think a central authority is necessary as long as we have the web of identity / trust. If requested anyway, what about haskell.org? -- 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

Presumably for SSL you either need to:

- Buy an expensive certificate from a known CA (maybe there are free / cheap ones?)

InstantSSL sells certs for $50/year. You may be able to find it even cheaper elsewhere.

- Trust any old certificate that comes along

You can also trust a finite set of certificates that you have personally verified (just like personally verifying GPG keys).

- Build a web of trust for signing certificates, just the same as for gpg. Is there a way to do this? GPG has built-in ways to do this, does SSL?

Yes. Most SSL installations have ways of adding root certs, certs for entities that you trust to sign other certs. e.g. we can make haskell.org a root cert. Look, cryptographically GPG and SSL are very similar. With either one, if you trust long chains of signings, you are at risk that any intervening key has been compromised. So, in practice, you rely on a set of root certs/signers you trust to * put some effort into verifying the mapping from a key to an identity, * maintain their private keys sufficiently securely that you can trust it for long periods of time, and * notify you when keys they have signed have been compromised. Whether you use GPG or SSL, operation of this key certification and revocation service has real costs. We can choose an identity model for the Haskell community that reduced these costs, but that is orthogonal to whether we use SSL or GPG. The real differentiator between SSL and GPG is that the former is transport level while the later is file level. With SSL, I think you suffer additional complexity each time you set up a web server. With GPG, you suffer additional complexity each time you create a new file to share. I think most people create many more files to share than they set up web servers to serve them so I prefer the SSL model. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Tue, 17 May 2005, Isaac Jones wrote:

Shae Matijs Erisson writes:

...

Isaac Jones writes:

...

How does one generate a signed SSL certificate? It's very costly, isn't it?

It's free to generate a self-signed certificate, but that doesn't help much. As you suggest later in this email, there could be a CA on haskell.org.

But how do you configure your browser / client to trust that certificate? I guess in web browsers it usually tells you that it's signed by an unknown CA, do you want to trust it, then you can click through.

Presumably for SSL you either need to:

- Buy an expensive certificate from a known CA (maybe there are free / cheap ones?)

- Trust any old certificate that comes along

- Build a web of trust for signing certificates, just the same as for gpg. Is there a way to do this? GPG has built-in ways to do this, does SSL?

Thanks for the GPG HOWTO!

peace,

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

As a point of clarity, we're not discussing using SSL for Hackage, this part of the thread is about Alex's SearchPath tool. (snip)

Look, cryptographically GPG and SSL are very similar. With either one, if you trust long chains of signings, you are at risk that any intervening key has been compromised.

I agree. My only question is really in tool support and keyring / certificate management. For instance, are there tools like gnupg where you can interactively browse and sign keys, upload signatures to central keystores, have sets of trusted vs untrusted keys, etc. I've found SSL to be very hard to work with, though I suppose you could automate things, and I wouldn't be surprised to hear if there are tools like gnupg for SSL certs. I'd be glad to hear that, actually :) (snip)

The real differentiator between SSL and GPG is that the former is transport level while the later is file level. With SSL, I think you suffer additional complexity each time you set up a web server. With GPG, you suffer additional complexity each time you create a new file to share.

We don't "suffer additional complexity". You merely type in your key password when uploading a single tarball. That is "cabal-put foo-1.0.tgz" ... type your password.

I think most people create many more files to share than they set up web servers to serve them so I prefer the SSL model.

Many people who want to share packages don't configure their own web servers. peace, isaac

John Meacham writes:

I strongly think that hackage need not worry or deal with web of trust or identity at all (but like using gpg for end-to-end security a lot). Tying a gpg key to a physical identity is a big can of worms and frankly irrelevant for hackages purposes. What is important is that no one other than the author or an authors delegate is able to modify a package after it has been created. To enforce this, all that is needed is to verify the gpg key matches the one that was used to initially create the project. that is all.

Hackage need not and should not worry whether a key is 'John Meacham's official key, or just a one-off key created for the specific purpose of managing a hackage project or the identity of an AI that writes haskell packages in its infinite spare time. The whole idea of tying a key to an existential identity is flawed, let the key _be_ the identity and all problems go away.

Note that this doesn't mean that people can't match keys to individual state issued identities if they want, but that will be specifically orthogonal to hackage which only cares about matching keys and not what is behind them.

In a sense, that's what I'm proposing... It's just that in my version, we _also_ have a set of keys which are tied to identities for those who care. There are flaws in having keys tied to identities, but it is definitely an extra layer of security. peace, isaac

On Thu, May 19, 2005 at 06:02:48PM -0700, John Meacham wrote:

On Thu, May 19, 2005 at 04:30:47PM -0700, Isaac Jones wrote:

...

John Meacham writes:

...

I strongly think that hackage need not worry or deal with web of trust or identity at all (but like using gpg for end-to-end security a lot). Tying a gpg key to a physical identity is a big can of worms and frankly irrelevant for hackages purposes. What is important is that no one other than the author or an authors delegate is able to modify a package after it has been created. To enforce this, all that is needed is to verify the gpg key matches the one that was used to initially create the project. that is all.

Hackage need not and should not worry whether a key is 'John Meacham's official key, or just a one-off key created for the specific purpose of managing a hackage project or the identity of an AI that writes haskell packages in its infinite spare time. The whole idea of tying a key to an existential identity is flawed, let the key _be_ the identity and all problems go away.

Note that this doesn't mean that people can't match keys to individual state issued identities if they want, but that will be specifically orthogonal to hackage which only cares about matching keys and not what is behind them.

In a sense, that's what I'm proposing...

It's just that in my version, we _also_ have a set of keys which are tied to identities for those who care. There are flaws in having keys tied to identities, but it is definitely an extra layer of security.

I just think it needs to be clear that any such network is purely optional and independent of hackage. Trust networks are complicated but useful beasts, and it should not be that hackage is taking on this complication, but rather able to make use of it if desired.

Here are two plausable things I might care about when downloading a package 'foo'.

A) That it was written by the John Meacham who lives in pasadena, ca and went to Caltech that I know personally and trust to not put anything malicious in.

B) That is was written by the author of package 'foo' who I trust because I have read and used their code in the past and it is top notch.

note, a key ring is only needed to answer questions about A, but not B. I surmise that B is the method most people will care about since as a group, we mainly know about each other online and anyone we know in person we can just ask for the public key of.

I would go further and say a trusted key ring actually gives a false sense of security when it isn't used to verify people you 'trust' for other reasons. If Billy Badperson asked me to sign his key saying he was Billy Badperson then I would do so, because all I am asserting is that he is who he claims (and I'd rather him identify himself than be anonymous!). NOT that he won't introduce mallicious or buggy code.

I'm not sure about the debian keyring, but what I mean by a "keyring" is B, not A. I don't *think* that keyring is synonymous with "web of trust". So the debian developers keyring holds only the keys of debian developers, *not* all keys signed by debian developers. Similarly, I'd hope that a hackage keyring would be limited to the keys "persons known to have contributed to hackage." Which is more like what you would like. This is something I've thought about a bit in the context of signed binaries/tarballs for darcs--how we would make known who is authorized to create an "official" darcs binary or tarball. Tarballs are easier, since it's just me and Tomasz, but most of the people who make darcs binaries are unknown to me. (And even Tomasz might actually be a hyperintelligent AI program for all I know...) :) -- David Roundy http://www.darcs.net