Bug#845565: Bug#853066: gnupg-agent: opens dialog on the wrong computer.

[Teemu Likonen]

Teemu Likonen [2017-02-05 11:44:27+02] wrote:

> I'll just confirm the above and add that even executing
>
> gpg-connect-agent updatestartuptty /bye
>
> on the remote ssh session shell (Bash) doesn't help. I tried
> gpg+pinentry with this command on the remote ssh session:
>
> gpg -ac <<< message
>
> and pinentry-gnome3 opens its password prompt window in the running
> desktop session (XFCE4 in my case).

But one thing that helps is loopback mode for pinentry:

gpg -ac --pinentry-mode loopback <<< message

So maybe one solution for the (remote) shell sessions' pinentry problem
is a shell alias like this:

alias gpg="gpg --pinentry-mode loopback"


signature.asc
Description: PGP signature

Bug#845565: Bug#853066: gnupg-agent: opens dialog on the wrong computer.

[Teemu Likonen]

Charles Plessy [2017-01-31 22:57:07+09] wrote:

> Le Sun, Jan 29, 2017 at 10:35:10PM +0900, Charles Plessy a écrit :
>> when I am logged on my desktop computer directly with a GNOME shell
>> session, and remotly via SSH, attempts to use gpg from the SSH
>> session will open a popup on my desktop computer's screen to enter
>> the passphrase, which obviously prevents me from entering the
>> passphrase when I am far from the desktopp computer (which is why I
>> connect to it via SSH).

> Like in Adam's and Vincent's cases, if I have a graphical session
> open, then my passphrase will be asked in this graphical session, even
> if I ran gpg in a SSH sesion and I have no physical access to my
> graphical sesssion. This happens regardless of the screen being locked
> or not, and setting GPG_TTY or unsetting DBUS_SESSION_BUS_ADDRESS did
> not help to solve the problem.

I'll just confirm the above and add that even executing

gpg-connect-agent updatestartuptty /bye

on the remote ssh session shell (Bash) doesn't help. I tried
gpg+pinentry with this command on the remote ssh session:

gpg -ac <<< message

and pinentry-gnome3 opens its password prompt window in the running
desktop session (XFCE4 in my case).

My test environment is the current Debian testing in virtual machine
(Qemu) and ssh connection was made from the host machine.


signature.asc
Description: PGP signature

Bug#845565: Bug#853066: gnupg-agent: opens dialog on the wrong computer.

[Charles Plessy]

Control: reassign 853066 pinentry-gnome3
Control: reassign 845565 pinentry-gnome3
Control: forcemerge 845565 853066 841909

Le Tue, Jan 31, 2017 at 03:38:23PM +0100, Vincent Lefevre a écrit :
> On 2017-01-31 22:57:07 +0900, Charles Plessy wrote:
> > Control: forcemerge -1 845565
> 
> Note that the bug was merged to itself. Do not use -1 when several
> bugs are mentioned in To/Cc. I think that both bugs 845565 and
> 853066 should be reassigned to pinentry-gnome3, *then* forcemerge'd
> with bug 841909.

Argh, sorry for the mess !

> > Do you think it might help to put the Debian GNOME maintainers in the
> > loop ?  Perhaps there is a GNOMEish way to ensure that the GNOME tools
> > are launched in GNOME context, and text tools are launched in text
> > context.
> 
> In my case, I do not use GNOME at all, but expect X11 tools in a X11
> context (e.g. pinentry-gtk-2). IMHO, either pinentry-gnome3 should
> detect the context and do the necessary fallback(s), or a pinentry
> wrapper should be preferred to the alternatives system: it would
> detect the context and launch the right pinentry-* program (with
> fallback when not installed).

Indeed, I think that pinentry-gnome3 should not be called in this
context.  For instance, from my SSH session, if I type `sudo apt install
foo`, my password is prompted in text mode in the SSH session, not as a
popup on a distant computer.  Similarly, if I type `exit`, then the SSH
session where I entered the command is ended; I do not get a popup on
the distant computer asking if I want to close the graphical session
instead.  I think that the gpg ~ gpg-agent ~ pinentry chain should to the
same: prompting the user at the location where the user ran the command,
as it used to do in Jessie.

I understand that this UI problem is quite far from what the Debian
GnuPG Maintainers are able to commit to solve, and that the freeze is
near.  So where is the best place to call for help ?  Perhaps
planet.debian.org ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#845565: Bug#853066: gnupg-agent: opens dialog on the wrong computer.

[Vincent Lefevre]

On 2017-01-31 22:57:07 +0900, Charles Plessy wrote:
> Control: forcemerge -1 845565

Note that the bug was merged to itself. Do not use -1 when several
bugs are mentioned in To/Cc. I think that both bugs 845565 and
853066 should be reassigned to pinentry-gnome3, *then* forcemerge'd
with bug 841909.

> Do you think it might help to put the Debian GNOME maintainers in the
> loop ?  Perhaps there is a GNOMEish way to ensure that the GNOME tools
> are launched in GNOME context, and text tools are launched in text
> context.

In my case, I do not use GNOME at all, but expect X11 tools in a X11
context (e.g. pinentry-gtk-2). IMHO, either pinentry-gnome3 should
detect the context and do the necessary fallback(s), or a pinentry
wrapper should be preferred to the alternatives system: it would
detect the context and launch the right pinentry-* program (with
fallback when not installed).

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

Bug#845565: Bug#853066: gnupg-agent: opens dialog on the wrong computer.

[Charles Plessy]

Control: forcemerge -1 845565

Le Sun, Jan 29, 2017 at 10:35:10PM +0900, Charles Plessy a écrit :
> 
> when I am logged on my desktop computer directly with a GNOME shell
> session, and remotly via SSH, attempts to use gpg from the SSH session
> will open a popup on my desktop computer's screen to enter the
> passphrase, which obviously prevents me from entering the passphrase
> when I am far from the desktopp computer (which is why I connect to it
> via SSH).

> I am not completely sure if it is the same as with #559101, therefore
> I open a new bug.

Hi Daniel and everybody,

I figured out that it is the problem described in #845565 and #842015.

Like in Adam's and Vincent's cases, if I have a graphical session open,
then my passphrase will be asked in this graphical session, even if I ran
gpg in a SSH sesion and I have no physical access to my graphical
sesssion.  This happens regardless of the screen being locked or not, and
setting GPG_TTY or unsetting DBUS_SESSION_BUS_ADDRESS did not help to
solve the problem.

Here are the related packages installed on my system.

ii  dbus-user-session 1.10.14-1  
ii  gnupg-agent   2.1.18-3   
ii  gnupg22.1.17-2   
ii  pinentry-gnome3   1.0.0-1

I would expect that if I type a command in one shell (SSH or GNOME),
then related dialogs gets prompted in the same shell.  Thus, I do not
understand why pinentry-gnome3 is being used when I am not calling GPG
from a terminal started in the GNOME shell.  To me, it is a big
regression from Jessie, where I was able to SSH to my home computer and
run gpg from my SSH session.

Do you think it might help to put the Debian GNOME maintainers in the
loop ?  Perhaps there is a GNOMEish way to ensure that the GNOME tools
are launched in GNOME context, and text tools are launched in text
context.

Have a nice day,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#853066: gnupg-agent: opens dialog on the wrong computer.

[Charles Plessy]

Package: gnupg-agent
Version: 2.1.18-3
Severity: normal

Hello,

when I am logged on my desktop computer directly with a GNOME shell
session, and remotly via SSH, attempts to use gpg from the SSH session
will open a popup on my desktop computer's screen to enter the
passphrase, which obviously prevents me from entering the passphrase
when I am far from the desktopp computer (which is why I connect to it
via SSH).  This happens when I have used gpg in the GNOME shell session
directly, and enough time lapsed so that the agent wants the passphrase
again.  Otherwise, gpg in the SSH session just runs without asking the
passphrase.

I am not completely sure if it is the same as with #559101, therefore
I open a new bug.

Have a nice day,

-- Charles

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (500, 'stable-updates'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages gnupg-agent depends on:
ii  libassuan0  2.4.3-2
ii  libc6   2.24-8
ii  libgcrypt20 1.7.5-3
ii  libgpg-error0   1.26-1
ii  libnpth01.3-1
ii  libreadline77.0-1
ii  pinentry-gnome3 [pinentry]  1.0.0-1
ii  pinentry-gtk2 [pinentry]1.0.0-1

Versions of packages gnupg-agent recommends:
ii  gnupg  2.1.18-3

Versions of packages gnupg-agent suggests:
ii  dbus-user-session  1.10.14-1
ii  libpam-systemd 232-14
ii  pinentry-gnome31.0.0-1
pn  scdaemon   

-- no debconf information