hackage, cabal-get, and security

Isaac Jones ijones at syntaxpolice.org
Thu May 19 19:30:47 EDT 2005

John Meacham <john at repetae.net> writes:

> I strongly think that hackage need not worry or deal with web of trust
> or identity at all (but like using gpg for end-to-end security a lot).
> Tying a gpg key to a physical identity is a big can of worms and frankly
> irrelevant for hackages purposes. What is important is that no one other
> than the author or an authors delegate is able to modify a package after
> it has been created. To enforce this, all that is needed is to verify
> the gpg key matches the one that was used to initially create the
> project. that is all. 
> Hackage need not and should not worry whether a key is 'John Meacham's
> official key, or just a one-off key created for the specific purpose of
> managing a hackage project or the identity of an AI that writes haskell
> packages in its infinite spare time.  The whole idea of tying a key to an
> existential identity is flawed, let the key _be_ the identity and all
> problems go away. 
> Note that this doesn't mean that people can't match keys to individual
> state issued identities if they want, but that will be specifically
> orthogonal to hackage which only cares about matching keys and not what
> is behind them.  

In a sense, that's what I'm proposing...

It's just that in my version, we _also_ have a set of keys which are
tied to identities for those who care.  There are flaws in having keys
tied to identities, but it is definitely an extra layer of security.



More information about the Libraries mailing list