Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Daniel Kahn Gillmor]

On Thu 2016-11-10 04:50:08 -0800, Vincent Lefevre wrote:
> No, this is wrong. In this case, the user isn't necessarily using
> the graphical session.

as far as the graphical session is aware, the user is using it.

> I don't use gnome-keyring, but the dependency on pinentry comes
> from gnupg-agent, which has:
>
> Depends: pinentry-curses | pinentry, [...]
>
> However, pinentry-curses is not installed by default because
> pinentry-gnome3 is already installed via gnome.

yes, via evolution → gnome-keyring.  that's why i'm recommending that
you reassign this bug to gnome-keyring

> Perhaps it should have a Recommends on pinentry-curses or
> pinentry-gtk2 to make sure that by default, pinentry-gnome3 is not the
> only one installed.

No, not pinentry-curses -- pinentry-curses is unable to talk to
gnome-keyring's secretservice.  gnome-keyring should Depend: on pinentry
packages that can talk to the secretservice.  

> IMHO, the correct solution would be to detect whether GNOME is used,
> and with a wrapper, select pinentry-gnome3 in this case, and
> pinentry-gtk2 otherwise when available.

how do you propose to detect whether GNOME is used?  Who will maintain
such a wrapper?

> Note that pinentry-gtk2 remains superior for non-GNOME users (and
> for GNOME users who connect by SSH), because it will still be able
> to display a graphic window (which users may prefer to curses) even
> with SSH + X forwarding, contrary to pinentry-gnome3, if I understand
> correctly.

I beg to differ -- i'm a non-GNOME user and pinentry-gnome3 works quite
well with gcr on my machine.

> Otherwise, test some environment variable(s), either in pinentry-gnome3
> or in Gcr via a communication of the value with pinentry-gnome3 (but
> I think that the communication would be overkill in practice).

Please be concrete.  This back-and-forth is causing me to miss out on
other productive work.

  --dkg


signature.asc
Description: PGP signature

Bug#842015: [pkg-gnupg-maint] Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Daniel Kahn Gillmor]

On Thu 2016-11-10 01:39:32 -0800, Werner Koch  wrote:
> On Wed,  9 Nov 2016 00:41, d...@fifthhorseman.net said:
>
>> dbus-user-session is also very much in line with gpg-agent's
>> --standard-socket option (which is now the default): both of them have
>> the concept of a single session running for any given user on the
>> machine.
>
> In GnuPG that depends on the GNUPGHOME and not on the user.

yes, iiuc, all of this discussion has been about the default use of gpg,
with GNUPGHOME unset.

 --dkg

Bug#842015: [pkg-gnupg-maint] Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Werner Koch]

On Wed,  9 Nov 2016 00:41, d...@fifthhorseman.net said:

> dbus-user-session is also very much in line with gpg-agent's
> --standard-socket option (which is now the default): both of them have
> the concept of a single session running for any given user on the
> machine.

In GnuPG that depends on the GNUPGHOME and not on the user.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpLDzJFMoq6o.pgp
Description: PGP signature

Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Daniel Kahn Gillmor]

Control: tags 842015 + help

On Wed 2016-11-09 01:57:41 -0600, Vincent Lefevre wrote:
> OK, but it uses dbus. So, there should be a way with dbus to know
> whether the user is currently using the graphical session.

We *do* know whether the user is currently using the graphical session.
The user is logged in at the graphical console, has a gcr-prompter
available, and the screen is not locked.

>> i'm sorry, but if this bug report depends on the user using manual
>> window placement with fvwm, i'm inclined to close it wontfix.
>
> That's just an example. The fault does not come from fvwm, but
> entirely from pinentry/Gcr, which opens a window on the wrong screen.

gcr opens a window on the screen where it knows the user is logged in,
present, and not locked.  right?

>> > On a default Debian desktop system, pinentry-gnome3 is installed:
>> >
>> > cventin:~> aptitude why pinentry-gnome3
>> > i   evolution Depends evolution-data-server (>= 3.22.1)
>> > i A evolution-data-server Depends gnome-keyring
>> > i A gnome-keyring Depends pinentry-gnome3  
>> 
>> on a default debian system, the user has the GNOME lockscreen and the
>> GNOME window placement, and the screen will lock when they leave it long
>> enough to get to an ssh client elsewhere and connect in.
>
> No, not everyone uses GNOME on a default Debian system.

The default debian desktop system used GNOME the last time i tried to
install it.

>> If you have a concrete test that you think we could implement in
>> pinentry-gnome3, i'm game to entertain it.  Please test.  But if what
>> you want is a pinentry that strictly follows the currently-attached X11
>> session (rather than following the attached d-bus session), you might
>> want to just use a different pinentry.
>
> Then that should be the default.

The default for a GNOME desktop is to integrate well with GNOME. Your
main concern here is that gnome-keyring depends on pinentry-gnome3 and
no other pinentry.Perhaps you'd like to reassign this bug report to
gnome-keyring and ask them to:

Depend: pinentry-gnome3 | pinentry-gtk2

instead, so that you can purge pinentry-gnome3 without it yanking
evolution.  pinentry-gtk2 is capable of stashing and restoring passwords
with the SecretService that gnome-keyring provides, so they should be OK
with that.

I'm marking this bug with "help" because i'm at my wit's end here.  I
understand the situation you've described.  I do think it's a corner
case (most people don't ssh into any machine, let alone into a
workstation that they're currently logged into), and you have many other
options to work around it that you refuse to do:

 0) log out of your workstation when you leave it.

 1) let GNOME lock your screen automatically, or lock it when you leave
 the workstation.

 2) use pinentry-gtk2 or pinentry-qt or pinentry-curses instead of
pinentry-gnome3
 
 3) purge dbus-user-session so that ssh sessions do not talk to the same
d-bus session as the graphical session

 4) manually export DBUS_SESSION_BUS_ADDRESS=/dev/null inside your ssh
connection so that anything running there knows not to talk to dbus,
ever

If you have a more constructive suggestion for how to resolve it, i'm
happy to hear it.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Vincent Lefevre]

On 2016-11-08 17:41:54 -0600, Daniel Kahn Gillmor wrote:
> From the dbus-user-session package description:
> 
>  This model merges all parallel non-graphical login sessions (text
>  mode, ssh, cron, etc.), and up to one graphical session, into a
>  single "user-session" or "super-session" within which all
>  background D-Bus services are shared.

This is unclear because ssh + X forwarding should not be regarded
as a non-graphical login session.

> > pinentry-gnome3 could remain unaware of displays if gcr-prompter
> > communicates with it via d-bus. For instance, gcr-prompter could
> > ask the values of some environment variables. Since gcr-prompter
> > is the program that does the display, it should know what to ask.
> > That would be the obvious thing to do in order to decide which
> > display to use.
> 
> perhaps you'd like to reassign this bug to gcr-prompter?  I'm not
> convinced that they would accept it -- gcr-prompter is attached to a
> single d-bus session, and if that d-bus session has a graphical session
> associated with it, it uses that session.

But with the concept of "super-session", this way of doing doesn't
make sense. Before using the graphical session, it should make sure
that it has been called from this graphical session.

> >> But pinentry-gnome3's end-user prompts currently work even when they're
> >> run from a process where DISPLAY has unset for whatever reason.  It
> >> sounds like you're asking to break this functionality.
> >
> > I actually don't understand why this should work: unsetting DISPLAY
> > is a way to prevent from processes using X.
> 
> Right.  And pinentry-gnome3 does not itself use X.

OK, but it uses dbus. So, there should be a way with dbus to know
whether the user is currently using the graphical session.

> > I'm not asking to break this functionality, because there could be
> > another test before testing DISPLAY. But one needs to know why a
> > user would want an X dialog window while DISPLAY has been unset.
> > And in this case, how the display is determined.
> 
> What test are you imagining?  Most users don't want an "X dialog window"
> -- they want a graphical window where possible, and they have no idea
> what DISPLAY is :/

Most users don't need to know. DISPLAY is inherited from the
environment.

> i'm sorry, but if this bug report depends on the user using manual
> window placement with fvwm, i'm inclined to close it wontfix.

That's just an example. The fault does not come from fvwm, but
entirely from pinentry/Gcr, which opens a window on the wrong screen.

> we're already in a corner case (ssh to a machine where the same user
> is already logged in on the graphical console)

This is certainly not a corner case.

> of a corner case (and the graphical screen isn't locked, despite
> that we're working with sensitve secret key material),

The machine is in a locked room, and I'm the only one to have the key.

> > On a default Debian desktop system, pinentry-gnome3 is installed:
> >
> > cventin:~> aptitude why pinentry-gnome3
> > i   evolution Depends evolution-data-server (>= 3.22.1)
> > i A evolution-data-server Depends gnome-keyring
> > i A gnome-keyring Depends pinentry-gnome3  
> 
> on a default debian system, the user has the GNOME lockscreen and the
> GNOME window placement, and the screen will lock when they leave it long
> enough to get to an ssh client elsewhere and connect in.

No, not everyone uses GNOME on a default Debian system.

> If you have a concrete test that you think we could implement in
> pinentry-gnome3, i'm game to entertain it.  Please test.  But if what
> you want is a pinentry that strictly follows the currently-attached X11
> session (rather than following the attached d-bus session), you might
> want to just use a different pinentry.

Then that should be the default.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Daniel Kahn Gillmor]

Hi Vincent--

On Tue 2016-11-08 10:23:22 -0600, Vincent Lefevre wrote:
> Yes, dbus-user-session got installed automatically as a consequence
> of dependencies.

dbus-user-session is also very much in line with gpg-agent's
--standard-socket option (which is now the default): both of them have
the concept of a single session running for any given user on the
machine.

> I see, a gcr-prompter process appears when I run gpg...

yes, launched due to
/usr/share/dbus-1/services/org.gnome.keyring.SystemPrompter.service

> So, the problem occurs only because with dbus-user-session installed,
> ssh and X shares a d-bus session.
>
> Now, how does gcr-prompter decide which display to use? The problem
> may be here. This does not come from dbus-daemon, since as documented
> in the dbus-daemon(1) man page:
>
>   The per-session daemon is used for various interprocess communication
>   among desktop applications (however, it is not tied to X or the GUI in
>   any way).

From the dbus-user-session package description:

 This model merges all parallel non-graphical login sessions (text
 mode, ssh, cron, etc.), and up to one graphical session, into a
 single "user-session" or "super-session" within which all
 background D-Bus services are shared.

> This depends on how gcr-prompter currently decides which display to
> use.

it uses the graphical session attached to the dbus session.  if there is
no graphical session, it fails in a noticeable way, which is when we
choose to fall back to text.

> pinentry-gnome3 could remain unaware of displays if gcr-prompter
> communicates with it via d-bus. For instance, gcr-prompter could
> ask the values of some environment variables. Since gcr-prompter
> is the program that does the display, it should know what to ask.
> That would be the obvious thing to do in order to decide which
> display to use.

perhaps you'd like to reassign this bug to gcr-prompter?  I'm not
convinced that they would accept it -- gcr-prompter is attached to a
single d-bus session, and if that d-bus session has a graphical session
associated with it, it uses that session.

>> But pinentry-gnome3's end-user prompts currently work even when they're
>> run from a process where DISPLAY has unset for whatever reason.  It
>> sounds like you're asking to break this functionality.
>
> I actually don't understand why this should work: unsetting DISPLAY
> is a way to prevent from processes using X.

Right.  And pinentry-gnome3 does not itself use X.  It uses the gcr
prompter, which it talks to over d-bus.  We're going around in circles
on this bug report, and i'm starting to feel diminishing returns.

> I'm not asking to break this functionality, because there could be
> another test before testing DISPLAY. But one needs to know why a
> user would want an X dialog window while DISPLAY has been unset.
> And in this case, how the display is determined.

What test are you imagining?  Most users don't want an "X dialog window"
-- they want a graphical window where possible, and they have no idea
what DISPLAY is :/

>> Another possible approach would be to prompt via the terminal *in
>> addition* to prompting graphically, if the current d-bus session knows
>> about an X11 session, but that X11 session does not match the current
>> value of $DISPLAY (e.g. if $DISPLAY is unset, or if it is set to a
>> different value).
>
> The graphical prompt when unexpected is also itself a problem.
> For instance, it can make other applications freeze while the
> user hasn't acknowledged the new window via his window manager.
> I use fvwm's manual placement and it is currently a problem.
> So, it shouldn't be "in addition".

i'm sorry, but if this bug report depends on the user using manual
window placement with fvwm, i'm inclined to close it wontfix.  we're
already in a corner case (ssh to a machine where the same user is
already logged in on the graphical console) of a corner case (and the
graphical screen isn't locked, despite that we're working with sensitve
secret key material), and i need to focus what debian/GnuPG packaging
energies are available on things that affect more people.

> On a default Debian desktop system, pinentry-gnome3 is installed:
>
> cventin:~> aptitude why pinentry-gnome3
> i   evolution Depends evolution-data-server (>= 3.22.1)
> i A evolution-data-server Depends gnome-keyring
> i A gnome-keyring Depends pinentry-gnome3  

on a default debian system, the user has the GNOME lockscreen and the
GNOME window placement, and the screen will lock when they leave it long
enough to get to an ssh client elsewhere and connect in.

If you have a concrete test that you think we could implement in
pinentry-gnome3, i'm game to entertain it.  Please test.  But if what
you want is a pinentry that strictly follows the currently-attached X11
session (rather than following the attached d-bus session), you might
want to just use a different pinentry.

  

Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Daniel Kahn Gillmor]

On Tue 2016-11-08 02:55:22 -0600, Vincent Lefevre wrote:
> Then, there should be another mean (I don't know which one) so that
> pinentry-gnome3 displays the prompt at the right place, e.g. when
> the user has an X session open locally on the machine but also
> accesses the machine remotely via ssh and the user runs gpg from
> this remote access.
>
> Communicating with the d-bus session only doesn't seem to be enough
> since DBUS_SESSION_BUS_ADDRESS has the same value under X and via ssh.

they do share a d-bus session in some circumstances (e.g. when
dbus-user-session is installed), and they do not in others.  But I hear
you that the situation you want changed is happening when they do share
a session.

> It should use the information about the current screen. Under X11,
> this comes from DISPLAY (I don't think there's another way because
> the user can choose where something should be displayed by directly
> changing the value of DISPLAY, and disregarding DISPLAY would not
> honor this requirement). For wayland, probably WAYLAND_DISPLAY, but
> according to the package description, only X and text terminals are
> currently supported by pinentry-gnome3: "If the X Window System is
> not active then an alternative text-mode dialog will be used."

I consider this a bug in pinentry-gnome3's documentation -- it does not
care about the X Window system at all, but rather uses d-bus.

> And if you mean that pinentry-gnome3 should delegate the display
> to GNOME so that it doesn't have to know whether X or wayland or
> whatever is used, then fine, but:
>
> * It should still have a fallback to X / terminal when GNOME is not
>   used (this is my case here).

If Gcr (the GNOME crypto kit, which includes the system prompter) is not
available on the current d-bus session, pinentry-gnome3 *does* fall back
to the terminal.  Are you suggesting that we should be checking for some
other test?

> * It should be able to detect whether the user is in front of his
>   GNOME session or accesses the machine in some other way (e.g.
>   ssh from a remote machine).

Can you recommend a mechanism for this?  What would you test?

We could simply test for the presence of $DISPLAY *even though
pinentry-gnome3 doesn't need it* and fall back if it is unset.

But pinentry-gnome3's end-user prompts currently work even when they're
run from a process where DISPLAY has unset for whatever reason.  It
sounds like you're asking to break this functionality.

Another possible approach would be to prompt via the terminal *in
addition* to prompting graphically, if the current d-bus session knows
about an X11 session, but that X11 session does not match the current
value of $DISPLAY (e.g. if $DISPLAY is unset, or if it is set to a
different value).

To begin that work, we'd need to be able to query d-bus about what
current X11 session it believes it is attached to.  I don't know how to
do that.  do you?

>> Perhaps you mean to be using pinentry-gtk-2?
>
> pinentry-gnome3 is used by default, so in any case, it should work
> correctly.

pinentry-gnome3 is used by default if it is installed.  But the default
pinentry that will be installed if you just "apt install gnupg" will be
pinentry-curses.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Vincent Lefevre]

On 2016-11-07 23:15:19 -0500, Daniel Kahn Gillmor wrote:
> On Sun 2016-11-06 04:25:27 -0500, Vincent Lefevre  wrote:
> > No, this is not a timeout issue, as a window is opened on the
> > X display, while it should never do that when DISPLAY is unset.
> 
> DISPLAY has nothing to do with how pinentry-gnome3 works.
> pinentry-gnome3 does not communicate with any X11 session -- it
> communicates with a d-bus session.

Then, there should be another mean (I don't know which one) so that
pinentry-gnome3 displays the prompt at the right place, e.g. when
the user has an X session open locally on the machine but also
accesses the machine remotely via ssh and the user runs gpg from
this remote access.

Communicating with the d-bus session only doesn't seem to be enough
since DBUS_SESSION_BUS_ADDRESS has the same value under X and via
ssh.

> > I don't use GNOME at all, so this isn't this scenario. But the above
> > would not be OK for GNOME & SSH users anyway. IMHO, what matters is
> > whether DISPLAY is set or not, and its value when it is set.
> 
> It sounds like you are expecting the beahvior of pinentry-gtk-2 (which
> does indeed talk directly to an X11 display), but using pinentry-gnome3
> instead (which talks instead to a d-bus session).  We could make
> pinentry-gnome3 test for the presence of DISPLAY, and fall back if it is
> unset, but why would we do this, if pinentry-gnome3 doesn't even assume
> X11?  If a user runs gnome3 in some non-x11 environment (wayland?  i
> don't know specifically), should pinentry-gnome3 fall back to curses,
> even when it can provide a graphical prompt?

It should use the information about the current screen. Under X11,
this comes from DISPLAY (I don't think there's another way because
the user can choose where something should be displayed by directly
changing the value of DISPLAY, and disregarding DISPLAY would not
honor this requirement). For wayland, probably WAYLAND_DISPLAY, but
according to the package description, only X and text terminals are
currently supported by pinentry-gnome3: "If the X Window System is
not active then an alternative text-mode dialog will be used."

And if you mean that pinentry-gnome3 should delegate the display
to GNOME so that it doesn't have to know whether X or wayland or
whatever is used, then fine, but:

* It should still have a fallback to X / terminal when GNOME is not
  used (this is my case here).

* It should be able to detect whether the user is in front of his
  GNOME session or accesses the machine in some other way (e.g.
  ssh from a remote machine).

> Perhaps you mean to be using pinentry-gtk-2?

pinentry-gnome3 is used by default, so in any case, it should work
correctly.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Daniel Kahn Gillmor]

On Sun 2016-11-06 04:25:27 -0500, Vincent Lefevre  wrote:
> On 2016-11-06 01:13:53 -0500, Daniel Kahn Gillmor wrote:
>> If you want a pinentry that only speaks curses (and never tries to
>> integrate with a gnome3 session), you should install pinentry-curses and
>> either remove pinentry-gnome3, or place "pinentry-program
>> /usr/bin/pinentry-curses" in your gpg-agent.conf.
>
> I expect that the fallback to curses be automatic.

It is indeed automatic -- it falls back when it is unable to communicate
with a gnome3 prompter, which happens via d-bus.

>> One additional exacerbating factor that you're seeing is probably due to
>> the fact that pinentry-gnome3 doesn't currently respect the default
>> timeout.
>
> No, this is not a timeout issue, as a window is opened on the
> X display, while it should never do that when DISPLAY is unset.

DISPLAY has nothing to do with how pinentry-gnome3 works.
pinentry-gnome3 does not communicate with any X11 session -- it
communicates with a d-bus session.

>> Can you explain what you'd rather happen here?
>
> I don't use GNOME at all, so this isn't this scenario. But the above
> would not be OK for GNOME & SSH users anyway. IMHO, what matters is
> whether DISPLAY is set or not, and its value when it is set.

It sounds like you are expecting the beahvior of pinentry-gtk-2 (which
does indeed talk directly to an X11 display), but using pinentry-gnome3
instead (which talks instead to a d-bus session).  We could make
pinentry-gnome3 test for the presence of DISPLAY, and fall back if it is
unset, but why would we do this, if pinentry-gnome3 doesn't even assume
X11?  If a user runs gnome3 in some non-x11 environment (wayland?  i
don't know specifically), should pinentry-gnome3 fall back to curses,
even when it can provide a graphical prompt?

Perhaps you mean to be using pinentry-gtk-2?

Still at a loss as to how to resolve this bug report satisfactorily,

--dkg



signature.asc
Description: PGP signature

Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Vincent Lefevre]

On 2016-11-06 01:13:53 -0500, Daniel Kahn Gillmor wrote:
> If you want a pinentry that only speaks curses (and never tries to
> integrate with a gnome3 session), you should install pinentry-curses and
> either remove pinentry-gnome3, or place "pinentry-program
> /usr/bin/pinentry-curses" in your gpg-agent.conf.

I expect that the fallback to curses be automatic.

> One additional exacerbating factor that you're seeing is probably due to
> the fact that pinentry-gnome3 doesn't currently respect the default
> timeout.

No, this is not a timeout issue, as a window is opened on the
X display, while it should never do that when DISPLAY is unset.

> I have patches queued that will respect the timeout that will
> be uploaded shortly as 0.9.7-8, though.

This doesn't change anything (I haven't rebooted the machine this
time, but anyway, only the pinentry-* packages were upgraded).

> It's not clear to me what you actually want to happen here (which is why
> i've tagged this bug report with "moreinfo").  Can you help me
> understand?  Over on https://bugs.gnupg.org/gnupg/issue2818 i discuss
> the corner case where there is an active gnome3 session but it is
> screen-locked; pinentry-gnome3 could be made to fall back to curses in
> that scenario as well (by querying the state of the gnome screensaver),
> but that still wouldn't change the scenario that you describe above:
> 
>   if the user is connected to an active gnome3 session, and they are
>   talking to gpg-agent which is configured to use pinentry-gnome3,
>   gpg-agent's prompt will appear on the active gnome3 session.
> 
> Can you explain what you'd rather happen here?

I don't use GNOME at all, so this isn't this scenario. But the above
would not be OK for GNOME & SSH users anyway. IMHO, what matters is
whether DISPLAY is set or not, and its value when it is set.
Displaying the prompt on a different screen does not make sense.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Daniel Kahn Gillmor]

Control: tag 842015 + moreinfo

On Sat 2016-11-05 06:31:39 -0400, Vincent Lefevre wrote:
> Control: reopen 842015
> Control: found 842015 0.9.7-7
>
> On 2016-11-04 23:23:43 -0400, Daniel Kahn Gillmor wrote:
>> The three bugs above are all caused by a situation where the user wants
>> to use secret key material with gpg, while relying on pinentry-gnome3
>> with access to a d-bus session, but where that d-bus session has no
>> access to an expected GNOME session.
> [...]
>
> The problem is still there. Note that I've tried after upgrading then
> rebooting the machine to make sure that nothing from old software was
> running (in particular, I've noticed that otherwise, gpg-agent is
> still running after I log out of all my X / SSH / screen sessions).
>
> Basically:
>
> 1. Upgrade and reboot the machine A.
>
> 2. Log in with X.
>
> 3. Type "gpg -d file.gpg" and cancel at the pinentry-gnome3 prompt.
>
> 4. On some other machine, ssh to machine A.
>
> 5. In this ssh session, type "gpg -d file.gpg".
>
> Result: A pinentry window is opened on the X display of machine A
> and this gpg "freezes".

It's not freezing, it's waiting for the user of the GNOME3 session to
respond to the pinentry-gnome3 prompt.

When there is no GNOME3 session connected to the d-bus session, 0.9.7-7
does in fact fall back to curses as expected.

But when there's an active GNOME3 session, pinentry-gnome3 prompts via
the GNOME3 session.  This is why it's called "pinentry-gnome3".

> I confirm that the workaround (unset DBUS_SESSION_BUS_ADDRESS and
> kill gpg-agent) still works.

This is not an effective workaround, for several reasons:

 * you may be running other code that wants a dbus session, so unsetting
   it is not reasonable.

 * by killing gpg-agent and restarting it without a dbus session, you've
   removed the ability for gpg processes *within* the gnome3 session to
   actually prompt the user via gnome3's standard prompter.

If you want a pinentry that only speaks curses (and never tries to
integrate with a gnome3 session), you should install pinentry-curses and
either remove pinentry-gnome3, or place "pinentry-program
/usr/bin/pinentry-curses" in your gpg-agent.conf.

One additional exacerbating factor that you're seeing is probably due to
the fact that pinentry-gnome3 doesn't currently respect the default
timeout.  I have patches queued that will respect the timeout that will
be uploaded shortly as 0.9.7-8, though.

It's not clear to me what you actually want to happen here (which is why
i've tagged this bug report with "moreinfo").  Can you help me
understand?  Over on https://bugs.gnupg.org/gnupg/issue2818 i discuss
the corner case where there is an active gnome3 session but it is
screen-locked; pinentry-gnome3 could be made to fall back to curses in
that scenario as well (by querying the state of the gnome screensaver),
but that still wouldn't change the scenario that you describe above:

  if the user is connected to an active gnome3 session, and they are
  talking to gpg-agent which is configured to use pinentry-gnome3,
  gpg-agent's prompt will appear on the active gnome3 session.

Can you explain what you'd rather happen here?

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#841909: Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Vincent Lefevre]

Control: reopen 842015
Control: found 842015 0.9.7-7

On 2016-11-04 23:23:43 -0400, Daniel Kahn Gillmor wrote:
> The three bugs above are all caused by a situation where the user wants
> to use secret key material with gpg, while relying on pinentry-gnome3
> with access to a d-bus session, but where that d-bus session has no
> access to an expected GNOME session.
[...]

The problem is still there. Note that I've tried after upgrading then
rebooting the machine to make sure that nothing from old software was
running (in particular, I've noticed that otherwise, gpg-agent is
still running after I log out of all my X / SSH / screen sessions).

Basically:

1. Upgrade and reboot the machine A.

2. Log in with X.

3. Type "gpg -d file.gpg" and cancel at the pinentry-gnome3 prompt.

4. On some other machine, ssh to machine A.

5. In this ssh session, type "gpg -d file.gpg".

Result: A pinentry window is opened on the X display of machine A
and this gpg "freezes".

I confirm that the workaround (unset DBUS_SESSION_BUS_ADDRESS and
kill gpg-agent) still works.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)