[Top][All Lists]
[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
- Re: ELPA security, (continued)
- Re: ELPA security, Bastien, 2012/12/22
- Re: ELPA security, Bastien, 2012/12/22
- package.el + DVCS for security and convenience (was: ELPA security), Ted Zlatanov, 2012/12/22
- Re: package.el + DVCS for security and convenience, Nic Ferrier, 2012/12/24
- Re: package.el + DVCS for security and convenience, Bastien, 2012/12/24
- Re: package.el + DVCS for security and convenience, Ted Zlatanov, 2012/12/24
- Re: package.el + DVCS for security and convenience, Xue Fuqiao, 2012/12/24
- Re: package.el + DVCS for security and convenience, Stefan Monnier, 2012/12/24
- Re: package.el + DVCS for security and convenience, Ted Zlatanov, 2012/12/24
- Re: package.el + DVCS for security and convenience, Stephen J. Turnbull, 2012/12/24
- Re: package.el + DVCS for security and convenience,
Ted Zlatanov <=
- Re: package.el + DVCS for security and convenience, Stephen J. Turnbull, 2012/12/26
- Re: package.el + DVCS for security and convenience, Xue Fuqiao, 2012/12/27
- Re: package.el + DVCS for security and convenience, Ted Zlatanov, 2012/12/31
- Re: package.el + DVCS for security and convenience, Stephen J. Turnbull, 2012/12/31
- Re: package.el + DVCS for security and convenience, Ted Zlatanov, 2012/12/31
- Re: package.el + DVCS for security and convenience, Stephen J. Turnbull, 2012/12/31
- Re: package.el + DVCS for security and convenience, Ted Zlatanov, 2012/12/31
- Re: package.el + DVCS for security and convenience, Stefan Monnier, 2012/12/29
- Re: package.el + DVCS for security and convenience, Ted Zlatanov, 2012/12/31
- Re:package.el + DVCS for security and convenience (was: ELPA security), Phil Hagelberg, 2012/12/31