hackage, cabal-get, and security

[S. Alexander Jacobson]

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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>