Re: package.el + DVCS for security and convenience

[Ted Zlatanov <tzz@lifelogs.com>]

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

SJT> Ted Zlatanov writes:
>> 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.

SJT> I have no idea what you think you're proposing.

I hope that doesn't make my proposal less ideal.

SJT> Security reviews are expensive; I doubt you'll have anybody willing
SJT> to maintain GNU ELPA after a couple of months of that, unless you
SJT> pay handsomely, or you enlist a maintainer per package or so to
SJT> reduce the burden on individual maintainers to a manageable level.

Trust is expensive.  The alternative is to say "trust this code, though
we don't know what it is."  That's the current state of affairs.

There is certainly review of code that goes into GNU Emacs itself.  A
security exploit would be caught quickly (I hope, based on previous
cases like the file-local variable exploits).  It's not as high-profile
as the Linux kernel, perhaps, but still an important target.

The GNU ELPA, being enabled by default, should be treated the same.  But
because it's a network resource, we must use signatures to indicate
files in the GNU ELPA can be trusted, since we don't package the GNU
ELPA with Emacs itself.

In other words, we're building a web of trust around GNU Emacs because
we want to be able to install parts of it (hosted in the GNU ELPA)
optionally and over the network.  That's where "trust" matters.

I never said it would be cheap or easy to do this.  But I think the FSF
and GNU volunteers can handle the task, and I firmly believe reviewing
Emacs Lisp code is much easier than C, C++, Perl, etc. code.  I'll
volunteer my own time for these reviews, unless of course you or others
are opposed because it would make me a "security tzar" or because it's
felt I'm unqualified.  As I said, the alternative is the current "just
trust whatever we put online" model, which is certainly cheap to run.

SJT> The obvious candidates for the latter are the authors.

No.

SJT> If they are not security reviews, what's the point of reviewing at
SJT> all?  You just want signed commits, verifying that the commit was
SJT> actually received at the GNU ELPA.  AFAICS this can be done by a bot,
SJT> which checks the authors' signatures on the commits.

No.

Ted