Hey!

For some reason, upstream enabled the --no-grab option when asking for
passphrase by default. I didn't find any rationale behind this change. See:
https://github.com/gpg/gnupg/commit/3d78ae4d3de08398fabae5821045a3a1da6dadbe

I think this is a surprising change and a major security vector. It's
easy with a "follow mouse pointer" focus mode to get one password
typed in an IRC window instead. Default should be reverted to "grab".

In the meantime, I have added the "grab" option in my
~/.gnupg/gpg-agent.conf to avoid that.

- -- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental-debug'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gpg-agent depends on:
ii  gpgconf                     2.2.3-1
ii  libassuan0                  2.5.1-1
ii  libc6                       2.25-4
ii  libgcrypt20                 1.8.1-4
ii  libgpg-error0               1.27-5
ii  libnpth0                    1.5-3
ii  pinentry-curses [pinentry]  1.0.0-3
ii  pinentry-gtk2 [pinentry]    1.0.0-3

Versions of packages gpg-agent recommends:
ii  gnupg  2.2.3-1

Versions of packages gpg-agent suggests:
ii  dbus-user-session  1.12.2-1
ii  libpam-systemd     235-3
pn  pinentry-gnome3    <none>
pn  scdaemon           <none>

- -- no debconf information
-----BEGIN PGP SIGNATURE-----

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAlo02pISHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5oDQP/iXtvtEyQ5mojKL4Lbk/L/NIcH7bb1dW
VqUrjJdBwoBYJsmBFWk7LI1DZntHeNc3LFpqg88hnOFmWrEkRekuYlWpUcaFGSnE
Msrx7Gm/JrOEPPmZygZNAiLRoDYdCX60auQ9cSG942PX1W+6cRZ8HaDGuNqKv/FQ
BVQY0LbZE+qVe23FLrM4MkhDxKJZvyvHorBT5U0TDvczhRWAEkgBRJ8howO+76Ok
bNmoCd3Lht8ZLdygyouGVvcl75cTXT0L5cfobKo/7OsluSWl2uiolRpGEqkLWSHE
2zllv5IOQQoIffbetvkLHqg1LFRTLQAeOd5YksJWKN69fBnEgVV+3OzJ/f4/oLpN
dyPdFqC1d+e7e9hBTNcAAJWYXUj4klEqebFbi6vIr7WLBHGul4g3lVsgDgc3z/gy
syyqHLy3WT4pCppYwk/4O/aTKaD8aAK3V067IHva6H0k5qGfz6XMi9mlQP2uBqpJ
m0N4eMTAK+p0r2uAcAk7Lql/rMr5/QBx1EvUeFEGtyOy6/DBi7Kaa9+O2i+KkBr6
C/O4VieyDVsNJBEYxXt5LnKUw1ErsBQZ+M5mHYD6yWnGrrstwihFBEKOVS3BSRvX
7F9qEwM41K+XrBSe4VPAaIsVe9crlxcaggWW9wW3mV/kl3aRH0yLF/RUR9jTUkbe
oN4D/aAT7zhM
=p4tf
-----END PGP SIGNATURE-----

On Sat, 16 Dec 2017 09:34, bernat@debian.org said:

[ Please dont reference an arbirary repo mirror of gnupg.  Either use
  the Debian repo or upstream. ]

I don't think that this is a major security vector. In fact we even
considered to create keys by default w/o passphrase.  Most users don't
have a tightened up box and those who have that know what to do:

  * agent: Option --no-grab is now the default.  The new option --grab
    allows to revert this.

Over the years we have received so many request to allow c+p of the
passphrase and to treat the pinentry as a normal entry field.  On most
current desktops the grabbing does not work reliable or is ineffective
due to the underlying GUI system.  GNOME and macOS use there own
passphrase manager anyway and more or less bypass the pinentry.  On
Windows it has no effect either.  Also X and the need for grabbing is
more and more replaced by Wayland or whatever thing distros like these
days.

Under the general directive to make GnuPG easier to use for the masses
we changed some of the defaults.  Those who have a need for securing
there systems need to work up a lot on their configuration anyway, and
thus adding a few options to GnuPG is just one more point on a list of
hundreds of items to care about.

Back in the days when Debian defaulted to the most secure configuration,
the grab was of course justified.  When I install a new Debian box today
I have to disable a lot of services before I can reasonable say, I did
something to secure that box.  The question is whether we want to do
something against mass surveillance or help a small group of targeted
persons to secure their machines by default.  We can't do both.


Shalom-Salam,

   Werner