emacs-devel
[Top][All Lists]
Advanced

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

Re: ELPA security


From: Paul Nathan
Subject: Re: ELPA security
Date: Sun, 6 Jan 2013 21:32:11 -0800


[snip]
 
I think it's easier to simply require that every file have its own .sig
and avoid the verification chain from manifest to archive contents.
Then we rely on GPG to handle signing and verification for us, no matter
who actually generates the .sig files (as long as their signing key is
trusted by us).  I don't think checksums have any advantage there, but
maybe you see some?

I think the GNU ELPA maintainers should sign everything, but that's
debatable and not essential to the proposal.

AG> Since installing a package produces additional files, they should
AG> probably be listed in the manifest (without checksum) to ensure that
AG> no malicious files are planted upon installation.

I don't know if that's needed, but have no problem with it as a feature.

AG> That moves all the authenticity issues to the signatures or rather the
AG> trust you have in the keys used to produce them.

Yes, that's exactly what I'm trying to accomplish, instead of relying on
SSL/TLS or other transport-level solutions.



Hullo,

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

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

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

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


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

Kind regards,
Paul


 


reply via email to

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