Re: package.el + DVCS for security and convenience

[Ted Zlatanov <tzz@lifelogs.com>]

On Sat, 05 Jan 2013 12:25:41 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:
>> On Fri, 04 Jan 2013 13:11:09 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>> 
SM> The signatures should be added to the `archive-contents' file.
>> 
>> I think `archive-contents' should contain just the keys allowed to sign
>> the package, not the signatures whole.  Otherwise, for multi-file
>> packages, the file could get large and the format could be awkward.  To
>> support both single-file and multi-file packages, I propose a X.sig
>> signature file for each file X in the package directory hierarchy.

SJT> I think that's a lot uglier, and will force people to use special
SJT> tools to manipulate non-Emacs structures conveniently (ie, the file
SJT> system).  (N.B. I wrote "convenient", not "possible".)  OTOH, the raw
SJT> content of archive-contents is rarely of interest to users, and the
SJT> only software that knows how to manipulate archive-contents is Emacs,
SJT> anyway.  Write a mode to display archive-contents, suppressing
SJT> signatures by default, and you're done AFAICS.

I'm OK with either approach, but feel that modifying and re-signing
`archive-contents' every time any file in the GNU ELPA changes is
awkward and not as easy.  In addition, it would make it hard to
distribute a subset of the GNU ELPA (e.g. a single package from it) if
there was a global registry of signatures.

>> I think it's better to have the GNU ELPA maintainers sign package
>> releases, not to delegate that to the authors.

SJT> I think that's a bad idea.  The responsibility is with the authors in
SJT> the first place; you're suggesting that it be delegated to the ELPA
SJT> maintainers.  All the ELPA maintainers can do is testify that they
SJT> built the package from sources in the repository.  Unless the
SJT> repository contains properly signed commits, that's not saying much.
SJT> Even then, for users it's a matter of indirect trust.  So for it
SJT> actually to be useful to security-conscious users, the ELPA
SJT> maintainers would have to vette the package authors -- *all*
SJT> committers.

SJT> It's really not that much work, and it's work that can and should be
SJT> decentralized.

I'm actually suggesting that the GNU ELPA maintainers (note the "GNU
ELPA" part here, this is not any ELPA maintainer) should review and sign
*every* commit to the GNU ELPA.  I feel this is an essential part of
building trust in the GNU ELPA (which started this discussion, and I
feel has been ignored as usual in favor of the technical discussion).

The alternative you propose is to trust many authors, which makes it
more likely that an author will be an attack vector, either through a
compromise of their own key, or by theft of identity, or because the
author was an attacker from the beginning.  I'd rather limit the number
of trusted keys to just a few.

Ted