Ludwig: Is that still an issue with a decent pinentry (0.9.1)?

Fixed with commit 726c005 for 0.9.2.

You will now get an gpg-error codes like ENOENT, ENOTTY and GPG_ERR_TOO_SHORT
and not always GPG_ERR_CANCELED. I was not able to replicate a crash but that
might have been fixed in an earlier version.

Fixed with commit d7f2081 for 0.9.2.

The report is quite old.
Let's assume that has been fixed by newer gtk versions.

Is that still a problem with the latest Pinentry (0.9.1 or 0.9.2)?

dkg and Neal fixed a couple of things recently. @neal: I think supporting C-W
in curses would a good idea.

That would require to send this string to all pinentries.

Fixed in:

commit 189ab07e94dc2d4103c1edf00e15e0156df89297
Author: Neal H. Walfield <neal@gnu.org>
Date: Fri May 1 20:35:59 2015 +0200

When reading the pin, correctly handle backspace.

* tty/pinentry-tty.c (read_password): Handle backspace.

--

I think this needs to be a bit clearer:

In pinentry-tty.c:confirm, only the "ok" button's text is shown and it is
suffixed by a fixed string: "[y/N]", which should be internationalized.

Well, it is only a warning and we should not remove the -Wstrict-prototypes
because it is in general very helpful. I suggest to use something similar to

#if JNLIB_GCC_HAVE_PUSH_PRAGMA

1. pragma GCC push_options
2. pragma GCC optimize ("no-strict-overflow")

#endif
....
pragma pop... but with the diagnostics pragmas.

Just pushed commit 9d2d8b6 which is the patch with some modification to avoid
gcc warnings. Will go into 0.9.2

Thanks.

This is still an issue with pinentry 0.9.1

Fixed with pinentry 0.9.1.

How much time would it take to migrate to QT5?

Should be fixed now.

The next version will no longer include the generated moc files.
It's not really a patch to backport (as you requested this in your mailing list).

In quilt you can just do something like:
quilt new remove-broken-moc-files.patch
quilt add qt4/*.moc
rm qt4/*.moc
quilt refresh

I also ran into this problem with our (intevation's) debian packaging.

Just removing the .moc files worked as they were correctly generated
automatically (as they should be).

I'll commit a fix not to include them in the dist package anymore.

Thanks!

Applied:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=484465338ea6f5f12eb1341ca0ef84aa79224ed4

D274: 536_0001-pinentry-qt4-make-the-accessibility-part-optional.patch

Werner: I think the source tarball you distribute should be changed not to
include the .moc files as they depend on the qt version used when you generate
the tarballs.

MOC should be detected during configure (and otherwise pinentry-qt should be
disabled) and MOC should be used to generate the moc files. If this does not
work as expected this might have been caused by my limited Make and autotools
skills ;-)

On 12/02/2014 10:14 PM, Daniel Kahn Gillmor via BTS wrote:

Daniel Kahn Gillmor <dkg@fifthhorseman.net> added the comment:

Any word on this? It would be nice to see something like this merged.

Any word on this? It would be nice to see something like this merged.

Thanks werner -- I've filed an upstream issue to bring awareness of the change
to the software I use that was affected (duply/duplicity), I'm sure this is
going to pop up for others as 2.1 becomes more widely adopted. Maybe add
something to the release notes or docs for '--passphrase-fd 0' so folks know a
config change is needed in their apps and gpg-agent? Regardless, I appreciate
your help.

(marking as resolved)

If you add it to gpg.conf the Pinentry won't be used and there are fir sure
cases where things won't work. In an unattended use I can't see a problem right
now.

We can't change the behaviour of --passpharse-fd; it is widely used and:

  if ( !opt.batch && opt.pinentry_mode != PINENTRY_MODE_LOOPBACK)
    { /* Not used but we have to do a dummy read, so that it won't end
         up at the begin of the message if the quite usual trick to
         prepend the passphtrase to the message is used. */

think would break or - worse - may insert the passphrase into the message.

The passphrase is still used for symmetric only encryption in batch mode.

Roger that, thanks - I've tested it on a VM with my keys and things seem "like
they used to be" for scripting an automated passphrase entry. I specified them
in my ~/.gnupg/pgp.conf and ~/.gnupg/gpg-agent.conf since editing many
individual softwares is not possible at this time, it needs to be backwards
compatible.

What side affects (breaking things?) does having these options permanently
enabled in configs are there? Having the allow in gpg-agent.conf is harmless,
but what about the client side gpg.conf?

If client gpg '--passphrase-fd 0' is useless without '--pinentry-mode loopback',
why not make this an automatic added option (internally) if '--passphrase-fd 0'
is specified? Of what use with gnupg-2.1.x is '--passphrase-fd 0' without
'--pinentry-mode loopback'?

I double-checked the official docs, there's no mention of needing these new
loopback settings in the section for --passphrase-fd 0:

https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html#GPG-Esoteric-Options

"If you use 0 for n, the passphrase will be read from STDIN." (but as we know
here, it's not unless the new loopback options are added)

Like gpgsm has done from its very beginnong, gpg now also does not pknow
anything about the secret keys. This is all delagted to gpg-agent. This means
that telling gpg a passphrase is useless.

But wait. There is a workaround: gpg has the new option

   --pinentry-mode mode
          Set the pinentry mode to mode.  Allowed values for mode are:

          default
                 Use the default of the agent, which is ask.

          ask    Force the use of the Pinentry.

          cancel Emulate use of Pinentry's cancel button.

          error  Return a Pinentry error (``No Pinentry'').

          loopback

                 Redirect Pinentry queries to the caller.  Note that
                 in contrast to Pinentry the user is not prompted
                 again if he enters a bad pass- word.

Thus by using

  gpg --pinentry-mode=loopback

you can do basically the same as with 1.4. It is well tested and
slighly different than in 1.4. Uou also need to configure gpg-agent
with

  --allow-loopback-pinentry

       Allow clients to use the loopback pinentry features; see the
       option pinentry-mode for details.

A few Arch users are reporting the same regression/breakage, thread here:

https://bbs.archlinux.org/viewtopic.php?pid=1479136

With pinentry 0.9 this works in pinentry-gtk under GNU/Linux.

With pinentry 0.8.4 This works in pinentry-qt4 under Windows.

Gpg4win includes a version with paste support since 2.1.0 (I think)

Feel free to send a patch ;-). You may want to publish this feature request on
some mailing list and ask for help.

pinentry-qt should have only been the default if you install a gpg4win version
that includes qt.

Could you execute pinetry-qt directly and enter "getpin" in the command line
window that opens?
What happens then?

Thanks for the explanations.

Further analysis showed that the second call to AllowSetForeground window was
blocked by the ForegroundWindowLockTimeout. If you set this timeout to zero
everything worked as expected.

There is a discussion on this under:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/09fa16ba-c6ef-410d-bec2-a99a9b9a98d9/issue-with-foregroundlocktimeout-setforegroundwindow

Which suggests a solution of setting the foregroundlocktimeout to zero before
attempting to set the foreground window. I've found this solution not applicable
for our case as we run into the lock on "AllowSetForegroundWindow" and not when
actually setting the foreground Window.

Another workaround is to call AttachThreadInput on the current foreground thread
call SetForegroundWindow and then detach again. There might be problems with
this approach so it is just used as fallback. But it should resolve this problem
for now.

What I described is done for all pinentries.

Ok, thanks I'll check what happens if

5. The agent thinks that the passphrase entered is too weak
6. The agent starts another pinentry
7. The agent sends "getinfo pid" to the pinentry (this i can see)
8. ?

1. The agent starts pinentry.
2. The agent sends "getinfo pid" to the pinentry"
3. The agents sends an "INQUIRE PINENTRY_LAUNCHED <pid>" to the caller.

4a. If the caller is gpg, gpg calls AllowSetForegroundWindow for the received
pid; gpg has been started via gpgme and gpgme has called ASFW for gpg.
4b. If the caller is gpgsm, it proxies the PINENTRY_LAUNCHED to gpgme which then
calls ASFG for the pid.

The different methods are required because gpg is a one-off process while gpgsm
may be used several times.

Yes Kleopatra uses gpgme for key generation. Still I don't see how gpgme figures
into this sorry. Should gpgme start gpg-agent and ensure that it has the
setforeground window access right?

1. The gpg-agent asks for a passphrase with pinentry -> set foreground window is

allowed.

2. If that passphrase is weak it launches a new pinentry with a confirm dialog

-> set foreground window is not allowed.

And the agent does not have the right to call allowsetforegroundwindow. In the
first case I think this might be because another component gets the PID of the
pinentry and calls allowsetforeground window (have to do further debugging to
check this)

In the second case afaik only gpg-agent is involved and no one sets
allowsetforeground window on the pid of the second pinentry.

BTW, gpgme 1.5.1 has a spawn interface which is better than to code your own in Qt.

It goes all the way back to GPGME via the assuan interface. grep for
_gpgme_allow_set_foreground_window. For GPG the assuan interface is not used.
We do it by passing our internal IOSPAWN_FLAG_ALLOW_SET_FG flag to the
gpgme-w32spawn.c helper which then uses this to call set foreground API.

Does Kleopatra always use gpgme?