From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: emacs-devel@gnu.org
Subject: Re: package.el + DVCS for security and convenience
Date: Thu, 27 Dec 2012 12:06:39 +0900 [thread overview]
Message-ID: <87d2xwtcqo.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <87bodg7v1t.fsf@lifelogs.com>
Ted Zlatanov writes:
> The same logic applies to using GnuTLS inside Emacs vs. gnutls-cli
> externally. I don't buy either argument.
Indeed I did apply it there, and good for you. But that's *just* you.
> Emacs is a platform and must make intelligent choices to protect
> the security of its users.
Yes. And one of those intelligent choices is to do well what Emacs
can do well, and leave up to the users what they can probably do
equally well, or mess up the best Emacs can do if they choose to be
security-unconscious.
The problem is that Emacs's security not only has to be better than
the users' to be useful, it has to be *much* better. As soon as *one*
application used by *millions* becomes responsible for security in
some area, it becomes not a security shield, but a vector for mass
attack -- cracked once, it exposes enough users to interest the black
hat pros.[1] Worse (IMO), that vector exposes security-conscientious
users to an "inside job".
Thing is, viewed from that point of view, I don't buy you (or Paul
Eggert, for that matter) as an authority on security good enough, or
available enough (which might extend to making security your day-in,
day-out contribution to Emacs) to make such decisions *for all Emacs
users*. You could sell me on that point, though. *You haven't
tried.* That is what worries me. I know, from embarrassing personal
experience, that smart people trying to be secure can be exploited.
It's not a question of your skills as a programmer, it's your attitude
as a "security officer" that doesn't thrill me.
> Depending on external binaries has always been a security issue that
> shifts the burden to the user and the system administrator.
That article "the" is a nice try, but I don't admit your sentence's
implicit assumption that the burden is monolithic. Every complex
system is going to have many security weaknesses, and the user is
*always* going to be #1 on that list (even if his name is "Bond. James
Bond."). There are many security burdens, and the implementation of
package checking is just one of them. There is a well-known "law"[2]
in social science called the "principle of second best," which may be
phrased "stronger may be weaker [because of interactions with the rest
of the system]". (An accurate phrasing would be "independent
component-wise improvements may interact to produce degraded system
performance.") It surely applies to security.
> (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 question is, which ones can and should Emacs take responsibility
for? Providing secure storage is surely one of them, because AFAIK
users can't do that themselves with an external tool. Some people who
do security as their "job number one" (ie, the folks who wrote the GPG
manual, I am not one of them and I don't know how widespread their
opinion is) seem to be saying that implementing the OpenPGP protocol
is not, because GPG provides a perfectly good tool to do the job.
I'm not welded to my "don't do this" position; I just think there are
a lot of things you could better do, and that it's a good idea to
limit the attack surface that *your* work presents. If you use GPG
cli tools, that surface is limited to the path(s) from the socket
talking to ELPA to the call-process call to gpg2. If you do signature
verification yourself, you *also* have to audit that implementation.
I think Emacs would be better off if you go after the "only Emacs
itself can do it" tasks first.
> 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,
No, it's not difficult to implement. But quis custodiet: what makes
you think your implementation itself won't be vulnerable to attacks,
many of which may not be under your implementation's control?
Again, I'm not saying "DON'T EVEN THINK of doing it", I'm suggesting
that you lack the skills and the humility to do a *sufficiently good
job for all Emacs users* because implementing *in* Emacs increases the
required level of quality by *orders of magnitude* as compared to
borrowing an existing, external implementation proved secure by long
experience. I suspect you lack the time to acquire the skills *and*
apply them *as required by security applications*, and you don't seem
to have a clue about the hubris.
Obviously, I could be wrong -- I *know* that *I* don't have the skills
required to judge whether your implementation is secure or not. I'd
just be a lot happier for Emacs if you seemed more aware of the
complexity and burden of the task you propose to undertake. And it
wouldn't hurt if, say, Paul Eggert were to speak up and say he
promises to do thorough reviews[2], and you could cite an authority
saying that the concerns of the GPG manual author are valid but
exaggerated, and ....
Footnotes:
[1] Not to mention that given the number of times GNU/FSF sites have
been hacked, some of the black hats seem to have it in for GNU. One
suspects that a Day Zero attack on ELPA might be quite a trophy in
some circles.
[2] It's a systematic contruction of counterexamples to monotonicity
rather than a positive law of nonmonotonicity.
[3] Which he would probably do anyway, of course (I know that he has
a more than passing interest in encryption, and I wouldn't be
surprised if he has qualifications and experience in other areas of
security as well). The point is that I think that Emacs deserves an
*explicit* commitment to do this well, and in the case of security,
that surely means *explicit* commitments to independent reviews, etc.
next prev parent reply other threads:[~2012-12-27 3:06 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-09 14:41 ELPA security George Kadianakis
2012-12-09 21:00 ` Nic Ferrier
2012-12-21 14:32 ` Ted Zlatanov
2012-12-21 22:12 ` Xue Fuqiao
2012-12-22 5:07 ` Bastien
2012-12-22 6:17 ` Xue Fuqiao
2012-12-22 12:34 ` Stephen J. Turnbull
2012-12-22 13:03 ` Bastien
2012-12-22 13:24 ` Bastien
2012-12-22 19:37 ` package.el + DVCS for security and convenience (was: ELPA security) Ted Zlatanov
2012-12-24 12:53 ` package.el + DVCS for security and convenience Nic Ferrier
2012-12-24 12:55 ` Bastien
2012-12-24 13:38 ` Ted Zlatanov
2012-12-24 13:39 ` Xue Fuqiao
2012-12-24 16:17 ` Stefan Monnier
2012-12-24 17:46 ` Ted Zlatanov
2012-12-25 1:03 ` Stephen J. Turnbull
2012-12-26 14:22 ` Ted Zlatanov
2012-12-27 3:06 ` Stephen J. Turnbull [this message]
2012-12-27 8:56 ` Xue Fuqiao
2012-12-31 11:18 ` Ted Zlatanov
2012-12-31 12:32 ` Stephen J. Turnbull
2012-12-31 13:50 ` Ted Zlatanov
2012-12-31 16:47 ` Stephen J. Turnbull
2012-12-31 21:41 ` Ted Zlatanov
2012-12-29 6:19 ` Stefan Monnier
2012-12-31 11:22 ` Ted Zlatanov
2013-01-03 16:41 ` Stefan Monnier
2013-01-04 16:05 ` Ted Zlatanov
2013-01-04 18:11 ` Stefan Monnier
2013-01-04 19:06 ` Ted Zlatanov
2013-01-05 3:25 ` Stephen J. Turnbull
2013-01-06 19:20 ` Ted Zlatanov
2013-01-07 2:03 ` Stephen J. Turnbull
2013-01-07 14:47 ` Ted Zlatanov
2013-01-08 1:44 ` Stephen J. Turnbull
2013-01-08 15:15 ` Ted Zlatanov
2013-01-08 17:53 ` Stephen J. Turnbull
2013-01-08 18:46 ` Ted Zlatanov
2013-01-08 21:20 ` Stefan Monnier
2013-01-09 2:37 ` Stephen J. Turnbull
2013-01-08 2:20 ` Stephen J. Turnbull
2013-01-08 14:05 ` Xue Fuqiao
2013-01-04 22:21 ` Xue Fuqiao
2012-12-31 20:06 ` Re:package.el + DVCS for security and convenience (was: ELPA security) Phil Hagelberg
2012-12-31 22:50 ` package.el + DVCS for security and convenience Ted Zlatanov
2012-12-22 16:20 ` ELPA security Stefan Monnier
2012-12-26 17:32 ` Paul Nathan
2012-12-31 11:50 ` Ted Zlatanov
2012-12-31 12:34 ` Stephen J. Turnbull
2012-12-31 13:39 ` Package signing infrastructure suggestion (was Re: ELPA security) Nic Ferrier
2012-12-31 22:32 ` Ted Zlatanov
2012-12-31 23:01 ` Xue Fuqiao
2012-12-31 19:48 ` ELPA security Tom Tromey
2012-12-31 19:57 ` Drew Adams
2012-12-31 22:19 ` Ted Zlatanov
2012-12-31 22:15 ` Ted Zlatanov
2013-01-05 16:46 ` Achim Gratz
2013-01-06 19:12 ` Ted Zlatanov
2013-01-07 5:32 ` Paul Nathan
2013-01-07 5:47 ` Jambunathan K
2013-01-07 5:53 ` Paul Nathan
2013-01-07 6:09 ` Jambunathan K
2013-01-07 6:20 ` Paul Nathan
2013-01-07 7:12 ` Stephen J. Turnbull
2013-01-07 7:18 ` chad
2013-01-07 14:34 ` Ted Zlatanov
2013-01-07 6:57 ` Stephen J. Turnbull
2013-01-07 14:35 ` Ted Zlatanov
2013-01-07 15:01 ` Ted Zlatanov
2013-01-08 3:07 ` Stefan Monnier
2013-01-08 14:47 ` Ted Zlatanov
2013-01-08 16:57 ` Stefan Monnier
2013-01-08 17:30 ` Ted Zlatanov
2013-01-08 20:50 ` Stefan Monnier
2013-01-08 21:30 ` Ted Zlatanov
2013-01-08 22:46 ` Stefan Monnier
2013-01-08 23:30 ` Ted Zlatanov
2013-03-12 18:29 ` Ted Zlatanov
2013-01-08 17:00 ` Stefan Monnier
2013-01-08 17:59 ` Achim Gratz
2013-01-08 18:37 ` Ted Zlatanov
2013-01-08 20:59 ` Stefan Monnier
2013-06-16 11:18 ` Ted Zlatanov
2013-06-16 23:12 ` Stefan Monnier
2013-06-17 1:56 ` Stephen J. Turnbull
2013-06-17 7:23 ` Ted Zlatanov
2013-06-17 15:54 ` Stephen J. Turnbull
2013-06-28 15:34 ` Ted Zlatanov
2013-06-17 14:34 ` Stefan Monnier
2013-06-17 7:20 ` Ted Zlatanov
2013-06-19 5:02 ` Ted Zlatanov
2013-06-19 12:38 ` Stefan Monnier
2013-06-23 11:58 ` Ted Zlatanov
2013-06-23 16:41 ` Stefan Monnier
2013-06-28 15:47 ` Ted Zlatanov
2013-06-28 16:28 ` Nic Ferrier
2013-06-28 22:49 ` Stefan Monnier
2013-06-24 3:44 ` Daiki Ueno
2013-06-28 15:32 ` Ted Zlatanov
2013-06-28 16:15 ` Daiki Ueno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d2xwtcqo.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.