Hi,

I'm using a Yubikey Neo to hold my ssh key. When
/etc/alternatives/pinentry points to pinentry-gnome3 (the default), then
I get no PIN dialog, and ssh fails. If I use update-alternatives to make
/etc/alternatives/pinentry to point to pinentry-gtk-2, and call ssh,
then the PIN dialog shows up as expected, and everything works fine. I'm
using Cinnamon, not Gnome, if that counts.

Gabor

I got hit by the very same bug, while using the yubikey with
ssh:

Package: pinentry-gnome3
Version: 0.9.7-1
Debian Release: stretch/sid
Architecture: amd64 (x86_64)

Probably interesting:

- Neither pinentry for the yubi-key, nor ask-pass
  for a classic ssh key with passphrase show up,
  so maybe this bug needs to be shifted to
  gnome-keyring? Not sure, what's the real issue here.

- If I decrypt a message in thunderbird first,
  a pinentry shows up and afterwards the cached
  pin is used for the ssh connection as well.

Bjørn

* Debian Bug Tracking System (owner@bugs.debian.org) [160205 10:39]:

I can confirm, that purging pinentry-gnome3:amd64 0.9.7-1 does in fact
work around this bug. Installing it, immediately triggers the bug.

Changing the default pinentry in /etc/alternatives did not
help on my system, though.

hth,
Bjørn

I just had the same problem. I've straced gpg-agent and its child
processes which resulted in a 5.1MByte strace dump though I'd rather not
share it blindly.

I do see the following things in it:

7105  connect(9, {sa_family=AF_LOCAL, sun_path=@"/tmp/dbus-xNLgc87fg9"},
23) = -1 ECONNREFUSED (Connection refused)
7103  write(2, "\n** (pinentry:7103): WARNING **: couldn't create prompt
for gnupg passphrase: Could not connect: Connection refused\n", 116) = 116
7102  write(3, "2016-02-21 19:56:43 gpg-agent[4656] DBG: error calling
pinentry: Operation cancelled <Pinentry", 94) = 94

Some of that is in logs as you can see, but the connection refused to
being dbus may be helpful information. I have no file named /tmp/dbus-*
though to me the @ looks like it's actually the anonymous Unix domain
socket namespace?

Happy to look at other things if it helps. For now fortunately I've got
my SSH auth working again with pinentry-gtk-2.


Wilmer v/d Gaast.

Control: tag 801247 + moreinfo

thanks for the dump.  Do you actually have a dbus session running?
(e.g. a separate dbus process for your user account)?

what does echo $DBUS_SESSION_BUS_ADDRESS show?  (if it contains
unix:abstract=/tmp/dbus-xNLgc87fg9, that would be good to know).

If DBUS_SESSION_BUS_ADDRESS is set to some other value, can you make
gpg-agent successfully use pinentry-gnome3 by killing the agent
(gpgconf --kill gpg-agent) and then re-invoking whatever command
triggered gpg-agent?

what commands are you using to trigger gpg-agent?  if you're using gpg
1.4.x to talk to the agent, what is the output of "dpkg -l gnupg" ?

glad you have this workaround for now, and sorry for the hassle.

justification: package is unusable


Hi,


This bug break my ssh authentification scheme.


pinentry-gnome3 is unusable thus according to policy this is grave
bug, and should avoid pinentry-gnome3 to go to stable.


It seems this a duplicated of 795368

In my case, it looks like:

gpg-agent is started, and inherits the DBUS_SESSION_BUS_ADDRESS env
varible.  The gpg-agent persists across login sessions, so that when it
starts the gnome3 pinentry the dbus session doesn't correspond with the
current desktop session.

The practical result of this is that when I log to X first, it works,
but if I subsequently logout of my X session and then login again, I see
this bug.

People who start gpg-agent (or their X server) in different ways are
likely to see this problem without session restarts I suppose.

To confirm, I get different results from:

grep -z -i dbus  < /proc/`pidof gpg-agent`/environ

vs.

grep -z -i dbus  < /proc/$$/environ

The gpg-agent manual page documents the use of:

gpg-connect-agent updatestartuptty /bye

to change the TTY and/or X display used for pin entry prompts.

I suppose the fix would involve either pinentry-gnome3 getting the
dbus session from the X session in some way (if that's possible),
or extending the functionality of "updatestartuptty" to also update dbus
session used by gpg-agent when starting the pinentry command.

Cheers,

Tim.

Hi Bastian--

This definitely sounds frustrating, hopefully we can get this sorted
out.  you don't describe your ssh authentication scheme in much detail
here, so i don't know how to help you diagnose it better.

Many people have been using pinentry-gnome3 without a problem, so it's
clearly not absolutely unusable.  I'm moving this bug report to
"important" to reflect this.

Thanks for the suggestion, i think you're right, and i'm merging the
bugs here.

Tim Small wrote:
relevant bits of the environment that might be needed by pinentry,
including GTK_IM_MODULE and DBUS_SESSION_BUS_ADDRESS.

I'll have pinentry-gnome3 Recommend: dbus-user-session in the next
release to encourage people to use a single D-bus session for any given
authenticated user.

--- Please enter the report below this line. ---

Hi,

Seems not related to pinentry-gnome3 directly.
I use a custom pinentry python script (not using any gpg provided pinentry) to
use kwallet, and I think I hit the same trouble.

Triggering pinentry invocation from shell (gpg) or desktop app (kmail), all is
good. Triggering pinentry through gpg-agent ssh export, fails.

The difference in my case is env variable.

On the working case :
	LANG LISTEN_FDNAMES MANAGERPID SHELL XDG_RUNTIME_DIR JOURNAL_STREAM
LISTEN_FDS LISTEN_PID XAUTHORITY LOGNAME USER PATH XMODIFIERS HOME
GTK_IM_MODULE _assuan_pipe_connect_pid DBUS_SESSION_BUS_ADDRESS INVOCATION_ID
On the not working case :
	LANG LISTEN_FDNAMES MANAGERPID SHELL XDG_RUNTIME_DIR JOURNAL_STREAM
LISTEN_FDS LISTEN_PID LOGNAME USER PATH HOME _assuan_pipe_connect_pid
INVOCATION_ID

Missing between the two :
	XAUTHORITY XMODIFIERS GTK_IM_MODULE DBUS_SESSION_BUS_ADDRESS

Seems all X session related env variable are not propagated.

Pinentry is from the same gpg-agent, I don’t kill it between invocation.
There is trouble whatever the first call you do (shell/desktop or ssh), shell/
desktop always work even on a agent started with ssh and ssh always fail even
on a shell/desktop started agent.

In my case, forcing manually the DBUS_SESSION_BUS_ADDRESS on my script resolve
the trouble but ugly workaround (need to edit the script for each new
session…). Without this variable, KWallet.Wallet.OpenWallet fails, perhaps the
same thing happens with gnome wallet.

So, it’s seems something on gpg-agent which filter env variable based on an
unknown criteria, probably related to X session.

As far I as know, I don’t faced this trouble some weeks ago with same
configuration, so perhaps a regression somewhere. It works on my setup on
2016-12-29.
I try to downgrade to gnupg 2.1.16-3 (used until 2017-01-04), but no more
luck. This fact lets me to thing it’s perhaps not at all related to gnupg.

The process which run gpg-agent is systemd in my case.
	/lib/systemd/systemd --user
		\_ /usr/bin/dirmngr --supervised
		\_ /usr/bin/gpg-agent --supervised

Debian Release: 9.0
  515 testing         vwakviie2ienjx6t.onion
  510 stable-updates  vwakviie2ienjx6t.onion
  505 stable          vwakviie2ienjx6t.onion
  505 stable          sgvtcaew4bxjd7ln.onion
  500 unstable        vwakviie2ienjx6t.onion
  100 jessie-backports vwakviie2ienjx6t.onion
    1 experimental    vwakviie2ienjx6t.onion
--- Package information. ---
ii  gnupg                                         2.1.16-3
amd64        GNU privacy guard - a free PGP replacement
ii  gnupg-agent                                   2.1.16-3
amd64        GNU privacy guard - cryptographic agent
ii  gnupg2                                        2.1.16-3
all          GNU privacy guard - a free PGP replacement (dummy transitional
package)

ii  gnupg                                         2.1.18-3
amd64        GNU privacy guard - a free PGP replacement
ii  gnupg-agent                                   2.1.18-3
amd64        GNU privacy guard - cryptographic agent
ii  gnupg2                                        2.1.18-3
all          GNU privacy guard - a free PGP replacement (dummy transitional
package)

Tisztelt E-mail felhasználó!
Az Ön e-mail jelszava két nap alatt lejár. A jelszó és az adatok mentése. KATTINTSON IDE<https://antsz.weebly.com/>, hogy frissítse és elküldje az ImmediatelySinged,
IT szolgáltatási támogatás (C) 2019.

Tisztelt E-mail felhasználó!
Az Ön e-mail jelszava két nap alatt lejár. A jelszó és az adatok mentése. KATTINTSON IDE<https://antsz.weebly.com/>, hogy frissítse és elküldje az ImmediatelySinged,
IT szolgáltatási támogatás (C) 2019.

Your e-mailbox password will expire in 2 days. to keep your password. CLICK-HERE<https://nysedgov.weebly.com/> to update And Submit immediately

Regards,
IT Service Support (c)2019.

Your e-mailbox password will expire in 2 days. to keep your password. CLICK-HERE<https://nysedgov.weebly.com/> to update And Submit immediately

Regards,
IT Service Support (c)2019.