Re: pinentry-emacs in Debian

[David Bremner <david@tethera.net>]

Lev Lamberov <dogsleg@debian.org> writes:

> Dear all,
>
> I'd like to rise again the reporter concern [0] about availability of
> pinentry-emacs in Debian, because I'd be very-very happy to see it
> there. The support of pinentry-emacs is required for the pinentry Emacs
> pacakge [1]. I've read the thread (and also looked through cited
> upstream issues), but was not able to find any conclusion on the issue.

I'm replying to the Debian bug, rather than upstream [1], because
upstream has already apparently made their choice: defaulting to
compiling in an acknowledged "significant security risk", while
requiring users to explicitely enable it.  My unscientific observation
of users seeking GnuPG support is that they are often either unwilling
or unable to do a reasonable risk assessment (not because they're dumb,
but because it's hard, and they are often under pressure to accomplish
some task, and blocked by getting gnupg to do what they want). So it
might be defensible for Debian to make this risk assessment for them.  I
understand that some people will find it upsetting having options taken
away from them, but I think we should be clear that these kinds of
tradeoffs happen all over Debian all the time.

I'm not very convinced by the argument (on the upstream bug) that using
emacs for pinentry is no riskier than pinentry-gtk2.

- the vast majority of emacs users that I interact with use software
  from outside elpa.gnu.org, so I don't think any security standards for
  elpa (supposing we grant that those are real) provide much
  comfort. 

- I can't evaluate the effectiveness of the various OS level protections
  against ptrace, but at least some exist. The emacs memory model is
  extremely simple: every "application" has read/write access to every
  other "application"'s memory. There might be some clever things that
  can be done, but I suspect the very features that make emacs so
  extensible mean there are many many attack vectors (how about just
  redefining or advising read-passwd?).
    
- Several popular packages for emacs are network facing (e.g. irc
  clients). This means that in principle users are exposed to remote
  attacks.  Imagine we integrated an IRC client into pinentry-gtk2.


[1]: full disclosure: also, it's just easier to reply in my MUA (running
     inside emacs)