Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Tue, 08 Jan 2013 10:44:36 +0900 "Stephen J. Turnbull" <address@hidden> 
wrote: 

>> On Mon, 07 Jan 2013 11:03:07 +0900 "Stephen J. Turnbull" <address@hidden> 
>> wrote: 

SJT> Ted Zlatanov writes:

>> The alternative is to say "trust this code, though we don't know
>> what it is."

SJT> Your use of the unique quantifier is once again inappropriate.  "We"
SJT> does not have to be an undifferentiated blob; it can be
SJT> personalized.

To an Emacs user, the GNU ELPA is a package archive, not a personality
bazaar.  Our view on emacs-devel is very different and colors our
thinking.  So "we" reflects us, the Emacs developers, of which the GNU
ELPA maintainers are a subset.

SJT> You could, for example, have each volunteer provide a separate
SJT> signature as they review the code.  More reviews, more trust -- maybe,
SJT> unless more reviews means each one is less thorough.  Identification
SJT> of the reviewer means trust can be a function of the reviewer.
SJT> Authors don't make the best reviewers, but they do know the code, and
SJT> an author signature is a certificate of authenticity.

I explained that authors are much easier to compromise than maintainers.

Stefan has confirmed (I believe) the GNU ELPA maintainers will use a
single "GNU ELPA" key to sign package releases.  He has also stated
we'll use signatures to indicate provenance, not security reviews.
Since I won't argue that point further, I've snipped your thoughtful
replies on the topic of security reviews, except where I could clearly
win the argument ;)

SJT> If you actually do reasonably thorough reviews, though, you will
SJT> end up with a large backlog of pending commits unless you have a
SJT> lot of volunteers.

I was planning to outsource it to some Russians.  They are very
thorough, I know the gang leader, er, I mean the project manager,
personally.

SJT> (Authors will have to rework features rejected for security of
SJT> implementation reasons, and it would be quite painful to have a
SJT> whole feature rejected for security reasons).

The authors are free not to host their packages in the GNU ELPA, if they
don't want to worry about security concerns.  Even without security
reviews, I think that should be the case, and the GNU ELPA maintainers
should be free to reject packages on that basis.

SJT> Nor do I see why reviewing Emacs Lisp code is *much* easier.

IMHO suspicious and malicious code is more easily visible in Emacs Lisp.

SJT> AFAIK you're not currently a GNU ELPA maintainer?

I have the access.

SJT> 0.  Emacs should do something about this, and soon.
SJT> 1.  Mission creep should be avoided.
SJT> 2.  The first mission, cheap to implement, is to authenticate the
SJT>     packages that are at GNU ELPA.

I agree.

SJT> 3.  The authentication should be done via a list of authorized
SJT>     signatures, not a single "GNU ELPA Maintainer" (GEM) signature.

SJT> 4.  Package maintainers (PMs) should be considered leading candidates
SJT>     for signing their own packages as pushed to GNU ELPA.  PMs should
SJT>     use a specific key exclusively for signing GNU ELPA packages for
SJT>     authentication purposes.

I think, at least for now, Stefan has decided to use a single signature.

SJT> 5.  The next mission is to develop security criteria for reviews.
SJT>     This will be an ongoing process, with basics ("don't load random
SJT>     libraries from the default directory") coming first, and more
SJT>     extensive reviews ("how could this hook be abused?") postponed
SJT>     until later.

SJT> 6.  Code that has been security reviewed would get a separate "SR"
SJT>     signature (ie, personal to the reviewer and a different key from
SJT>     either the GEM key(s) or the PM keys).

I think that's a good plan, and can coexist with the more urgent need
to sign the package to indicate provenance.

I propose security signatures also live in `archive-contents', as Yet
Another Vector Element, in an alist (reviewer . signature) format.

Ted