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
