hackage, cabal-get, and security
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 Isaac,
Thanks for doing this. It clarifies what we are protecting against and in my opinion is a pretty good solution. 1. How do we handle key management? For example, if I lose my key or someone hacks into my machine and steals my key. How do we revoke the key? If the package only accepts updates from a keyholder and the key is revoked, how do we issue a new key and allow the package to accept updates from the new keyholder? 2. How do I get a trusted key given I am not likely to meet anybody "trusted" in the near future? Registration is often a weak point in security schemes. 3. What constitutes a "trusted" key? Is it, if it signed by two people on the library mailing list? Dominic.
Dominic Steinitz writes:
1. How do we handle key management? For example, if I lose my key or someone hacks into my machine and steals my key. How do we revoke the key?
If GnuPG is used -- and I am strongly in favor of this --, then encourage contributors to generate the revocation certificate at the same time they generate the key itself. Then instruct them to put that certificate on a CD, DVD, or whatever, so that they can distribute it when the secret key is lost or compromised. Most people are unable revoke their keys because they have quite simply forgotten their pass phrase. If you have a revocation certificate already, that isn't a problem any longer. Since people will without a doubt lose the revocation certificates too, encourage them to generate keys that expire after a sensible period of time. Both GnuPG and PGP offer a pretty straightforward sub-keying mechanism which allows you to switch keys, say once a year, without losing the signatures that authenticate your key to others.
2. How do I get a trusted key given I am not likely to meet anybody "trusted" in the near future?
Unfortunately, that is impossible. Your best bet is to have everybody sign everybody else's key at every possible opportunity, and that still won't mean that the key Joe Doe downloaded from the Internet will be for real. Your best bet to ensure that the keys are authentic is to publish their fingerprints at every chance you get so that people can verify the key they downloaded through other means than a web site. Publishing fingerprints in the printed version of the Haskell standard would be a good start, for example.
3. What constitutes a "trusted" key?
There are no trusted keys. The decision of whether to trust a key or not _must_ be made by the person who downloads the package -- the user. Nobody else can make that decision for him. Peter
Peter Simons
2. How do I get a trusted key given I am not likely to meet anybody "trusted" in the near future?
Unfortunately, that is impossible. Your best bet is to have everybody sign everybody else's key at every possible opportunity, and that still won't mean that the key Joe Doe downloaded from the Internet will be for real.
For now, I'm thinking that a "trusted key", from Hackage's perspective, will be a that has a path, which I trust, from me to the keyholder. In particular, in the short term at least, I'm hoping that folks in Debian will be willing to sign Haskell users' keys. This is convenient since Debian Developers are scattered all over the world. There may even be one near you ;) To me, this is a high-enough bar. If anyone disagrees strongly with that, let me know, but please also suggest a solution. Why me? Because I have physical access to the box that Hackage will live on, and I have a good handful of trusted keys. (snip)
3. What constitutes a "trusted" key?
There are no trusted keys. The decision of whether to trust a key or not _must_ be made by the person who downloads the package -- the user. Nobody else can make that decision for him.
Right. Hackage will sign packages which are signed by keys that it trusts, and cabal-get will come with a hackage public key. I suppose cabal-get should ask whether or not to trust the hackage key by default upon installation. BTW, if anyone wants to help hack on this, let me know :) peace, isaac
Hello all, it seems like we search for a BIG solution for a small problem :) for automatically downloading of libraries used in some software - all we need is to know that we download library released by the same person who release the original library used to construct this software. it is no matter whether he was a Jesus Christ or Ben Laden or anyone else :) may be it's better to drop all the like-the-supermans games and follow the Task -> Requirements -> Solution path? -- Best regards, Bulat mailto:bulatz@HotPOP.com
participants (4)
-
Bulat Ziganshin -
Dominic Steinitz -
Isaac Jones -
Peter Simons