The loopback pinentry

Daniel Kahn Gillmor dkg at fifthhorseman.net
Wed Apr 20 23:25:25 CEST 2016


On Wed 2016-04-20 13:00:41 -0400, Bjarni Runar Einarsson wrote:
> It's when we want to play nice with desktop Linux users who
> already have gpg and a keychain and a desktop, but still want
> remote access to their Mailpile... that's the scenario where
> things get complicated. Those users would not be happy with a
> separate keychain/config/agent just for Mailpile, and they would
> also not be happy if we edited their main config, potentially
> other apps, their desktop integration or who knows what else.

So instead you're proposing to effectively silently edit everyone's main
config, whether they use mailpile or not?

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

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.

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?

from a shell, that looks something like:

 if [ -z "$(gpgconf --list-options gpg-agent | \
            awk -F: '/^allow-loopback-pinentry/{  print $10 }')" ]; then
   read -p 'mailpile needs allow-loopback-pinentry. can we set it? [y/N] " OK
   if [ "$OK" = y ]; then
     echo allow-loopback-pinentry:0:1 | gpgconf --change-options gpg-agent
     gpg-connect-agent reloadagent /bye
   fi
 fi

or, as you said, you could run your own agent.

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 ?

We're arguing about defaults here, not about functionality.  doesn't
mailpile already have the functionality it needs?  why change the
defaults?

> As far as I'm concerned this isn't about security - this is
> fixing a regression that took place in 2.0 which broke the
> ability to use gpg in an unattended/automated way. This proposal
> goes a long way to fixing that.

I'm all for fixing regressions, but i don't see why we should change the
defaults for this case.

         --dkg



More information about the Gnupg-devel mailing list