emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ELPA security


From: Ted Zlatanov
Subject: Re: ELPA security
Date: Mon, 07 Jan 2013 10:01:48 -0500
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux)

On Sun, 6 Jan 2013 21:32:11 -0800 Paul Nathan <address@hidden> wrote: 

PN> It appears that the simplest so far is to use per-package signature files
PN> for GPG verification, keeping the gpg pubkeys downloaded with gnu emacs or
PN> separately downloaded.  I am perhaps unlearned, but directly using version
PN> control seems like it would add some complexity. The idea of having a data
PN> file and a signature file seems to be much more straightfoward.

Yes, I think that's the agreement.  I'd rather keep a .sig for every
file instead of signing the whole package, because then you can package
the whole directory in one tarball or distribute it as source, but
that's a technicality IMO.

PN> Perhaps this could be most easily accomplished by some sort of
PN> post-download hook ("check package file to verify signature authenticity"),
PN> along with a list of known GPG keys stored in some ~/.emacs.d/package-keys
PN> folder.

Yup.  But EasyPG and GPG manage keys already, so perhaps the storage
should be through them, instead of external.

PN> One downside to this proposal seems to be that it would link gnu emacs with
PN> gnu privacy guard fairly tightly as a dependency. I see several aspects
PN> here (perhaps I am missing something) -

PN> - GPG could be compromised on the user's computer(this probably indicates
PN> all is lost)
PN> - GPG must be distributed with GNU Emacs, or else partially reimplemented
PN> in elisp. Some operating systems are not shipped with gpg.
PN> - The verification and import interfaces must be very simple and obvious to
PN> users ignorant in cryptography. It is no good if many people just disable
PN> it because it is too problematic to use.

Yup.  We discussed this and Stefan said that for now at least, we'll
live with the GPG dependency.  I think eventually we'll implement enough
of the OpenPGP protocol to do signature verification in C.  That would
address these concerns which I had as well, but it should not block us now.

PN> I have the idea that this idea is very simple to prototype if gpg can be
PN> shelled out to. A cursory reading of package.el suggests to me that
PN> package-download-transaction could have the verification added.  I could
PN> help out here if it is acceptable for a novice to help.

I believe EasyPG (epg.el) already has the functions to do all the
signature verification work securely (e.g. it does the data transfer to
GPG and back as securely as possible).  So the POC is definitely
possible.

I'd like to settle the signing keys (will it be the authors or a group
of GNU ELPA maintainers?); `archive-contents' (will its format change?);
and signature files (will we have one per file, one per package, etc.?)
questions first.  Also Tom Tromey and Paul Hagelberg and the other
package.el authors have not commented on our latest discussions, and I
think their voices are important as they have contributed so much of the
package.el code and design.

But if you want to start on a POC, please feel free.  I really think it
would be a good start and don't wish to discourage you.

Ted




reply via email to

[Prev in Thread] Current Thread [Next in Thread]