hackage, cabal-get, and security

[Dominic Steinitz]

> Dominic Steinitz writes:
> 
>  > 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 GnuPG is used -- and I am strongly in favor of this --,
> then encourage contributors to generate the revocation
> certificate at the same time they generate the key itself.
> Then instruct them to put that certificate on a CD, DVD, or
> whatever, so that they can distribute it when the secret key
> is lost or compromised. Most people are unable revoke their
> keys because they have quite simply forgotten their pass
> phrase. If you have a revocation certificate already, that
> isn't a problem any longer.
> 
> Since people will without a doubt lose the revocation
> certificates too, encourage them to generate keys that
> expire after a sensible period of time. Both GnuPG and PGP
> offer a pretty straightforward sub-keying mechanism which
> allows you to switch keys, say once a year, without losing
> the signatures that authenticate your key to others.
> 
Sounds reasonable. So I should generate a key with a revocation certificate on 
a secure medium but then only sign my package with a subkey with an expiry 
date. 

Is someone going to write this down so that we all know what the rules are 
when we use Hackage? 

There's going to have be instructions both for the packager and for the user 
of the package on downloading and using pgp. 

Do we need to agree on algorithms and key lengths etc?

I'm still not clear what happens with Hackage when I revoke my subkey. Can I 
use a new subkey and Hackage accepts this?

And assuming the worst, I have to revoke my master (can I call it that in 
pgp?) key, what does Hackage do? Someone has got to tell Hackage that there 
is now an association between the new key and me and therefore the package 
can be updated by things signed with the new key (i.e. by me).
> 
>  > 2. How do I get a trusted key given I am not likely to
>  > meet anybody "trusted" in the near future?
> 
> Unfortunately, that is impossible. Your best bet is to have
> everybody sign everybody else's key at every possible
> opportunity, and that still won't mean that the key Joe Doe
> downloaded from the Internet will be for real.
But less likely :-)
> 
> Your best bet to ensure that the keys are authentic is to
> publish their fingerprints at every chance you get so that
> people can verify the key they downloaded through other
> means than a web site. Publishing fingerprints in the
> printed version of the Haskell standard would be a good
> start, for example.
Good but I don't think this helps me get bootstrapped. I'll have to hope I 
meet up with someone trusted at some point.
> 
> 
>  > 3. What constitutes a "trusted" key?
> 
> There are no trusted keys. The decision of whether to trust
> a key or not _must_ be made by the person who downloads the
> package -- the user. Nobody else can make that decision for
> him.
I feared this but it's probably acceptable in this environment.

Dominic.