hackage, cabal-get, and security

[David Roundy]

On Thu, May 19, 2005 at 06:02:48PM -0700, John Meacham wrote:
> On Thu, May 19, 2005 at 04:30:47PM -0700, Isaac Jones wrote:
> > 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.
> 
> I just think it needs to be clear that any such network is purely
> optional and independent of hackage. Trust networks are complicated but
> useful beasts, and it should not be that hackage is taking on this
> complication, but rather able to make use of it if desired. 
> 
> Here are two plausable things I might care about when downloading a
> package 'foo'.
> 
> A) That it was written by the John Meacham who lives in pasadena, ca and
> went to Caltech that I know personally and trust to not put anything
> malicious in.
> 
> B) That is was written by the author of package 'foo' who I trust
> because I have read and used their code in the past and it is top notch.
> 
> note, a key ring is only needed to answer questions about A, but not B.
> I surmise that B is the method most people will care about since as a
> group, we mainly know about each other online and anyone we know in
> person we can just ask for the public key of.  
> 
> I would go further and say a trusted key ring actually gives a false
> sense of security when it isn't used to verify people you 'trust' for
> other reasons. If Billy Badperson asked me to sign his key saying he
> was Billy Badperson then I would do so, because all I am asserting is
> that he is who he claims (and I'd rather him identify himself than be
> anonymous!). NOT that he won't introduce mallicious or buggy code.

I'm not sure about the debian keyring, but what I mean by a "keyring" is B,
not A.  I don't *think* that keyring is synonymous with "web of trust".  So
the debian developers keyring holds only the keys of debian developers,
*not* all keys signed by debian developers.  Similarly, I'd hope that a
hackage keyring would be limited to the keys "persons known to have
contributed to hackage."  Which is more like what you would like.

This is something I've thought about a bit in the context of signed
binaries/tarballs for darcs--how we would make known who is authorized to
create an "official" darcs binary or tarball.  Tarballs are easier, since
it's just me and Tomasz, but most of the people who make darcs binaries are
unknown to me.  (And even Tomasz might actually be a hyperintelligent AI
program for all I know...)  :)
-- 
David Roundy
http://www.darcs.net