Re:package.el + DVCS for security and convenience (was: ELPA security)

[Phil Hagelberg <phil@hagelb.org>]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I propose to require signatures for ELPA packages and make package.el
> aware of signatures

Having just gone through this process for the Clojure community
repository, it might be helpful for me to describe what we ended up with
there.

We ended up creating a new repository for the signed releases, but this
had more to do with flaws in the existing repository than anything
related to security. But the gist of it was that each package uploaded
had to be accompanied by an .asc file that was checked at upload time
against a public key that we had on file for the maintainers. The plan
is to also have a repository-level key that's used to verify the fact
that the given signed package was uploaded at a given time; that way
were a key to be compromised it would be possible to ensure that the
package was uploaded before the key was revoked.

We are working on building up a web of trust within the community of
Clojure library developers, but this is a long-term goal. This kind of
model would probably be important to the community repositories like
Marmalade and MELPA, but the GNU repository can sidestep some of this
complexity because there's a central authority that everyone can trust.
However, I'd suggest that rather than having GNU sign the packages
directly, they could sign the keys of those maintainers who have
privileges to upload. That makes revocation possible.

For Clojure right now we have rudimentary checks to ensure that all the
packages in a dependency tree are at least signed, but we don't yet have
a mechanism to walk it to ensure that everything's signed by someone you
trust or trust transitively. But IMO it's important to start collecting
signatures as early as possible even if the tools to check it on the
client don't exist yet; in the long run you want to minimize the number
of published unverifiable packages.

I don't see any benefit to using version control tools on the client
side. It may make sense to use them to build the repository, but having
the repository consist simply of a pile of static files on disk is a
very valuable property that we shouldn't give up lightly.

Adding SSL to the existing implementation would be fairly easy and has
no downsides, so it should be done soon; it's low-hanging fruit that can
be improved quicker than adding signatures.

I would just like to add that I consider writing an OpenPGP
implementation in Emacs to be a very bad idea--we simply do not have the
resources to get the auditing that would be necessary to get this to a
level of quality that we could trust. Using GnuPG would be both quicker
to implement and result in much higher-quality code. If there are
concerns that people may not use it because it's difficult to install
then our efforts would be better spent on making it easier to install.

I'm very glad to see movement on this front though--the current state of
affairs is an improvement over everyone pulling packages in from the
wiki but still has a long way to go before it's something properly
trustworthy.

-Phil