hackage, cabal-get, and security

[Simon Marlow]

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