Re: package.el + DVCS for security and convenience

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

Ted Zlatanov writes:

 > 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.

So what?  I thought the point was to reassure the users about the
security of the packages they download, not to massage the egos of the
maintainers by reifying "their thinking" in the design of the signing
process.

The users, by and large, do not willy-nilly download all the packages,
and this will not change by adding a signing step to the release
process.  Many users are familiar with the maintainers of the packages
they do want, and would have opinions on the quality (including the
security) of the packages those maintainers upload that vary as a
function of the maintainer.

This *does* matter if it's the security of the package contents that
is represented by the signature.  It doesn't matter if the signature
only authenticates the download as a true GNU ELPA product.

 > 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?

 > He has also stated we'll use signatures to indicate provenance, not
 > security reviews.

OK, I happen to agree with Stefan that that is the place to start.
And I agree with both of you that in that case a single key used by
all those authorized to push to the "official" repo is appropriate.

 > 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.

You are highly skilled at missing the point.  This is a cost, even if
the authors willingly pay it.  What bothers me is proposing to impose
such costs on the project without estimating their size, let alone
explaining where the resources will come from.