Re: package.el + DVCS for security and convenience

["Stephen J. Turnbull" <stephen@xemacs.org>]

Stefan Monnier writes:
 > >> Stefan has confirmed (I believe) the GNU ELPA maintainers will use a
 > >> single "GNU ELPA" key to sign package releases.
 > > Have you given up on having every commit signed?
 > 
 > I haven't even tried to sign a single Bzr commit.

That is the way a lot of projects do it.  It's not zero-cost
(indirectly evidenced by the fact that such projects typically have a
lot of people paid directly or indirectly to work on them).

All that the proposed signing system does is eliminate man-in-the-
middle attacks on the transport of packaged Lisp.  This is worth
doing, because apparently it's trivial to suborn parts of the DNS, and
because it makes it possible to authenticate mirrors, all at low cost
to the maintainers and users.

Nevertheless, it does nothing to make GNU ELPA more secure than it
currently is against attacks on the code in the repo itself or on the
release process.  In the long run, is that good enough for Emacs?

 > Hell, I use GPG rarely enough, that I typically end up having to
 > create a new key because I can't remember the password I used for
 > the last one.

Me too. ;-)  I'm going to start learning, though.

 > And I worry about what happens if/when we restructure the repository
 > (currently we have a single Bzr branch with all packages in it (except
 > for Org), but we'll probably want to move to a setup where more packages
 > have their own branches, also we may move from Bzr to something else).

That is indeed potentially costly.  However, if you're not going to
consider eventually bearing such costs, my position is that you should
seriously consider doing nothing, since the system that will be
implemented provides very little assurance that the code is "safe".
Yet many naive users will see the signatures and assume they mean
something they don't.

 > And I'm not sure what would be the gain with such signatures: I'm
 > shocked to hear people would trust me, since I don't trust myself (and
 > some (former?) friends of mine know I'm not trustworthy).

You write as if you think my trust in you is absolute.  It's not; I
simply would trust your code more than I would some other folks'.
Among other things, it's well-organized and easy to read, which means
I can review it myself.

That is the whole point I was trying to make by writing that I would
trust you -- trust is relative, and a function of people as well as
systems.  And I put little weight on your statement that you're
shocked; people are often poor judges of their own worth.

 > [ For the record, I work in the context of certified programming,
 > where you don't want to trust people at all, and instead expect
 > them to give you a formal proof that their code is safe.  ]

I don't understand the relevance of that comment.  Since you have
disclaimed the intent to do security reviews, you obviously can't
possibly be providing formal proofs for code safety.  Nothing is left
except to recognize that in downloading and using packages (and Emacs
itself) users are implicitly trusting contributors who are many, do
not have easily verified identities, and in some cases are effectively
anonymous.  Of course we don't want to trust, but there is no
alternative to trusting somebody.  In the current state, we are forced
to trust everybody to the same degree.

 > > You are highly skilled at missing the point.

 > Let's try to stay clear of such ad-hominem, please.

It's not "argument ad hominem", but since the current plan is to
restrict signatures to authenticating provenance, it has become
irrelevant.  I retract the statement.