The loopback pinentry

[Bjarni Runar Einarsson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Daniel,

tl;dr: Whenever an app *can* copy all the key material and do as
it likes by changing GNUPG_HOME and writing out a custom gpg.conf
(or edit gpg.conf directly), then it is it pretty clear that the
current defaults for this setting provide no real security. They
just making things inconvenient, driving developers like myself
to hacky, dangerous workarounds or away from GnuPG entirely. I
think everyone agrees that this scenario is the common case.

Qubes would be an exception, if this changes for 2.2 we might
want to reach out to them and make sure they are aware of the
change. Are people aware of any other common cases where the
agent is actually isolated and protected from other apps run by
the same user?

Those are the main points IMO.

Discussion and answering individual points follow...


Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> 
> So instead you're proposing to effectively silently edit
> everyone's main config, whether they use mailpile or not?

No, we're talking about what should be the defaults for the next
stable release. I am not sure 2.0 even has the functionality
we're discussing, for some reason the GnuPG 2.0.28 on my box
appears to have shipped with a man page (and info) that describes
a bunch of 2.1 features that don't actually work. ;-)

Many of the people who have compiled GnuPG 2.1 from source and
use it regularly are probably on this list, so this is hopefully
a good place to discuss whether they would consider this a good
or bad thing for the next stable release.

> aiui, mailpile is implemented in a browser, with the backend
> handled by a sensible web framework.

Mailpile is not implemented in a browser, it offers a web
interface as one of its user interfaces. This means it can be
accessed simultaneously from afar and/or locally, depending on
the user. There's also a command-line interface which I use quite
a bit. :-)

> fwiw, if i were to run mailpile on my local machine, i'd
> *rather* have gpg-agent prompt me out-of-band, and avoid having
> my secret key passphrase handled by both my web browser and by
> the web framework.

That's your choice. It is a choice that means you won't be able
to do certain actions over the network (when you are away from
the desktop, you won't be able to fill out the pinentry). For
some users that is certainly the right thing, especially when we
consider signing and encrypting to be rare, meaningful actions.
But if you want to routinely, as a matter of course, encrypt and
sign everything, even if you're authoring it remotely using your
mobile phone - this becomes a major barrier.

Note that just because Mailpile wants loopback pinentry, that
doesn't automatically mean it is going to default to sending
passphrases over the network. It will frequently be used to
manage passphrases within Mailpile itself and silently provide
authentication as needed, without any user interaction at all.
Especially for keys that were generated by Mailpile in the first
place. I'd rather not generate them without a passphrase (so
Mailpile generates a strong random one), so I still need a way to
automate the authentication.

Since my goal is to get people encrypting and signing more and
more, I want to make it as convenient as possible. This is why I
care a great deal about use cases that differ from the one you
have described and differ quite a bit from the common ways GnuPG
is currently used. Maybe that's bad, maybe it's good, it depends
on your goals. :-)

Making the defaults (in both apps) friendly to non-technical
people, but providing knobs so the experts and folks with special
needs can lock things down seems like a good way to do things.
That *does* imply that you don't turn on all the lock-down
features by default. Somewhere you draw a line and say "this is
good enough".

> But if mailpile really does need to use the loopback, why not
> detect that allow-loopback-pinentry isn't set, and offer to set
> it for the user?

This is an option. I think it is a terrible one. As a matter of
principle (and sane engineering) Mailpile shouldn't be editing
your gpg.conf, ever.

I don't want to speak for Neal and Werner, but after discussing
with them, I did get the impression that they agree with me on
this.

> In fact, even if the defaults change, won't mailpile need to do
> this kind of work anyway to detect a situation where the user
> has explicitly placed no-allow-loopback-pinentry in their
> gpg-agent.conf ?

If a user has explicitly requested no loopback, then they
probably have a good reason and Mailpile should honour that and
gracefully fail in the remote scenarios the user has forbidden.
If the user only ever wants pinentry to happen through official
GnuPG interfaces, that is surely their choice and not one I want
to circumvent.

But a user that has never expressed a preference: is he really
better served by the current defaults? I am not the first (or
last) person to express frustration with how hard it is to
automate certain things with GnuPG 2+. The current defaults rule
out entire classes of interesting applications, for no obvious
security benefit.

Incidentally, saying "the user can just edit their config if they
want to use those apps" is tantamount to saying "non-technical
users are not allowed to use this software"... so I really hope
nobody says that! :-)

There are certainly cases where being able to lock down the setup
and disallow 3rd party pinentry is important for security. Having
the option to do so is useful. I just don't think that should be
the default, since it is largely meaningless in the common case
where all the apps run with the same UID and have direct access
to the keychain anyway.

Cheers,
 - Bjarni

- -- 
PageKite.net lets your personal computer be part of the web.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJXGAr3AAoJEI4ANxYAz5SRJl8H/iFjcTuWLpZCylp5pEpQQIgc
z5kEAp56+qPQdiuTVCWBcM39FIrdZMOa41zG5MLW3SOM+Vju1S7la4TFlKk8g0fc
LtO38Ffw45vgOfxgkiScN+mAf2Rb73sNdkKIe6LiWn0hN1Vh4Y/n2nijKubJ5Sqb
/RhRT1zSF9DdWOEoo9Z5kM3TD5QgTYrj3CDyEw6LhNjrKuEYbJTymkyuwyIma4sZ
Bk4RBvwI7YaG6YFp3R/8wLvflCRnd6aCidDjIGgZeRUVhIe8flFPil2vs/GC35ai
Ddw+57z2xtXqymvKB6cvuy9UHCDrWdA6bfbaq9gC1EJOCfMmzVA+BCq1mgftW4o=
=Hg/F
-----END PGP SIGNATURE-----