hackage, cabal-get, and security

Dominic Steinitz dominic.steinitz at blueyonder.co.uk
Tue May 17 15:20:34 EDT 2005


> 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.



More information about the Libraries mailing list