Re: package.el + DVCS for security and convenience

["Stephen J. Turnbull" <stephen@xemacs.org>]

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.