hackage, cabal-get, and security
john at repetae.net
Thu May 19 19:12:13 EDT 2005
On Mon, May 16, 2005 at 10:53:24PM -0700, Isaac Jones wrote:
> 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
> 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.
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.
John Meacham - ⑆repetae.net⑆john⑈
More information about the Libraries