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