Re: package.el + DVCS for security and convenience

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 27 Dec 2012 12:06:39 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Thing is, viewed from that point of view, I don't buy you (or Paul
SJT> Eggert, for that matter) as an authority on security good enough, or
SJT> available enough (which might extend to making security your day-in,
SJT> day-out contribution to Emacs) to make such decisions *for all Emacs
SJT> users*.  You could sell me on that point, though.  *You haven't
SJT> tried.*  That is what worries me.  I know, from embarrassing personal
SJT> experience, that smart people trying to be secure can be exploited.
SJT> It's not a question of your skills as a programmer, it's your attitude
SJT> as a "security officer" that doesn't thrill me.

I do not plan to be a "security officer," to prove my credentials to
your satisfaction, or to do it as a full-time job, yet I do plan to
contribute to Emacs security like I have before, gradually and carefully
after public discussion.  I encourage you and others to do the same.

>> (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.)

SJT> The question is, which ones can and should Emacs take responsibility
SJT> for?  Providing secure storage is surely one of them, because AFAIK
SJT> users can't do that themselves with an external tool.

I think you agree with the idea of secure storage being an Emacs
facility.  That is a long-term goal, like concurrency or lexical
bindings.

Similarly, Emacs needs a secure way to get data in and out of that
storage from external files or data.  Depending on an external binary
tool, *long-term*, to provide this transfer is IMO a poor security
decision for a platform such as Emacs.

>> 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,

SJT> No, it's not difficult to implement.  But quis custodiet: what makes
SJT> you think your implementation itself won't be vulnerable to attacks,
SJT> many of which may not be under your implementation's control?

Because it will be perfect, obviously.

Ted