emacs-devel
[Top][All Lists]
Advanced

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

Re: package.el + DVCS for security and convenience


From: Ted Zlatanov
Subject: Re: package.el + DVCS for security and convenience
Date: Wed, 26 Dec 2012 09:22:06 -0500
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux)

On Tue, 25 Dec 2012 10:03:28 +0900 "Stephen J. Turnbull" <address@hidden> 
wrote: 

SJT> The GPG documentation is full of warnings about doing it yourself, and
SJT> recommends using the GUI or the command-line interface.  ISTR at one
SJT> time they didn't even provide libraries (do they now?) for that reason.

SJT> I'm sure we've all seen some of the horror stories of what sometimes
SJT> happens to competent programmers who implement the protocols
SJT> themselves on RISKS (not to mention really terrifying stories like
SJT> "The 16,384 Keys of Debian").  Remember, as soon as Emacs distributes
SJT> something, hordes of users are potential users of the feature.  That
SJT> may make it an attractive target for an attack.  Anything built in to
SJT> Emacs needs to be *strong*.  Is it worth that much effort?

The same logic applies to using GnuTLS inside Emacs vs. gnutls-cli
externally.  I don't buy either argument.  Emacs is a platform and must
make intelligent choices to protect the security of its users.

Depending on external binaries has always been a security issue that
shifts the burden to the user and the system administrator.

(Also see my earlier suggestions about providing secure data storage at
the C level, so Emacs is not as vulnerable to core dumps to find user
passwords and other secrets.  There are many areas to improve.)

The OpenPGP protocol is described in http://tools.ietf.org/html/rfc4880
and thus fairly standard.  Verifying a signature, in particular, does
not require implementing the full protocol, and that's one of the
reasons I suggested it:

http://tools.ietf.org/html/rfc4880#section-2.5

SJT> Why not just start with the relatively easy optional verification of
SJT> signed files based on an installed OpenPG tool, and add pluggable
SJT> verification modules as people have interest?

I also think that's a good approach, as long as we keep the long-term
goals above in mind.

Ted




reply via email to

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