On 17 May 2005 15:19, S. Alexander Jacobson wrote:
My solution in SearchPath (released yesterday) is to rely on a combination of HTTPS and links.
I don't want to start another huge debate, but I think your solution at least lacks support for some fundamental (IMO) features: - versioning - pre-compiled libraries - FFI (external C libraries & bundled C code) What's your story for these? e.g. what you do intend to happen when someone imports Graphics.UI.WX? Cheers, Simon
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
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries