When I’m connected to my desktop computer via ssh, with the desktop computer’s desktop environment running and unlocked, trying to decrypt a gpg-encrypted file causes gpg-agent to invoke pinentry-gnome3 on the desktop. Assuming I’m physically elsewhere, I’m obviously unable to use the prompt on the desktop to enter the passphrase.

This happens despite both pinentry-tty and pinentry-curses being present on the desktop (in addition to pinentry-gnome3), and having GPG_TTY point to the correct tty (export GPG_TTY=$(tty)). Under these circumstances I’d expect gpg-agent to gracefully fall back to non-graphical alternatives.

Granted, I’ve so far only simulated being physically elsewhere by first ssh’ing out of the desktop, then back in again from the other end. If gpg-agent is using some kind of magic to detect that in reality I’m still physically on the desktop, then this report is invalid (although I’d still feel uneasy about such magic).

== Steps to reproduce ==
1. log in to desktop computer A
2. use another computer B to ssh in to the desktop computer
3. still physically on B, invoke `gpg -d encrypted.gpg` on A (over ssh)

== What happens ==
Graphical passphrase prompt pops up on A, while your ssh terminal on B waits

== What I expect to happen ==
For a non-graphical passphrase prompt (such as pinentry-tty or pinentry-curses) to appear on B’s ssh terminal

Upstream (based on a merged duplicate): https://dev.gnupg.org/T2011

When pinentry-tty is used to prompt for the password, interrupting the prompt using ctrl-c leaves the terminal only partially working: only some letter keys are echoed back.

The terminal remains in this broken state for about a minute, after which it resets itself and everything starts working again.

Below, I’m swiping through all alphabet and numeric keys of my keyboard at both 14.54, where only ”469+esgxb” gets through, and again at 14.55 (the last line), where they all come through.

14.54 jani@saegusa:testejä$ export LC_ALL=C
14.54 jani@saegusa:testejä$ { sleep 60; echo ”60 seconds passed”; } & LC_ALL=C /usr/bin/gpg -d passwords.gpg
[1] 12375
gpg: AES encrypted data
Enter passphrase

Passphrase:
gpg: signal Interrupt caught … exiting

14.54 jani@saegusa:testejä$ 469+esgxb^C
14.55 jani@saegusa:testejä$ 60 seconds passed

[1]+ Done { sleep 60; echo ”60 seconds passed”; }
14.55 jani@saegusa:testejä$ 1234567890+wertyuiopåasdfghjklöäzxcvbnm,.

== Steps to reproduce ==
1. Download https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Car_crash_1.jpg/193px-Car_crash_1.jpg?download
2. Open the image in Shotwell Viewer: $ shotwell 193px-Car_crash_1.jpg
3. Select File > Save As…
4. Keep/set Format as ”Current”, don’t change any other parameters
5. Enter ”193px-Car_crash_1.png” (without quotes) as the filename, select OK

== What happens ==
The viewer now displays a black screen, with the text ”Photo source file missing:” followed by the (.png-ending) image path entered in the dialog. The file has not been saved.

== What I expect to happen ==
For the (now misnamed) .png-ending file to have been saved, and be opened in the Viewer.

== Other notes ==
* If an image file with the .png ending already exists, and I choose to overwrite it with the JPEG, the black error screen does not appear; instead the previously-existing PNG image file is then opened in the viewer.
* I’m (intentionally) not doing an actual Format change in the first Save As dialog here. If I do select PNG as the format, then saving the file does work as expected (using any filename extension).
* I used .png just as an example here. Using any variant of /jpe?g/i as the extension seems to work as expected (i.e. the file is saved under the new name), whereas anything else (.gif, .foo etc.) results in the same ”file missing” error as above.
* If the original file is a PNG file, saving it with .jpg (or any other extension for that matter) seems to work as expected (i.e the file is saved under the new name, with the now-incorrect extension).

(My original report at Launchpad: https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1710641#. I tweaked some details for the report above, with Shotwell 0.27.4 currently in Bionic.)

@kubiko That’s good to hear, gives me confidence in running the snap on my main server again (instead of the VM). Thanks again guys!

@xet7 Alright, here’s hoping those fixes hit the spot! Thanks a lot.

And now, suddenly, it just works again.

root@saegusa:~# snap install wekan
wekan 0.77-29-g9e62584 from 'xet7' installed

root@battra:~# snap install wekan
2018/03/02 16:39:13.986937 cmd.go:212: DEBUG: restarting into "/snap/core/current/usr/bin/snap"
wekan 0.77-29-g9e62584 from 'xet7' installed

Darn it, I was hoping to catch the exact cause. Unless you guys already found and fixed it?

What’s changed on my end since I posted the last comment a week ago is the core snap updating from 4017 to 4110.

This is still present in Bionic.

$ LC_ALL=C apt-cache policy zsync
zsync:
Installed: 0.6.2-3ubuntu1
Candidate: 0.6.2-3ubuntu1
Version table:
*** 0.6.2-3ubuntu1 500
500 http://fi.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
100 /var/lib/dpkg/status
$ zsync http://cdimage.ubuntu.com/ubuntu-server/daily/current/bionic-server-amd64.iso.zsync
#################### 100.0% 0.0 kBps DONE

No relevent local data found – I will be downloading the whole file. If that’s not what you want, CTRL-C out. You should specify the local file is the old version of the file to download with -i (you might have to decompress it with gzip -d first). Or perhaps you just have no data that helps download the file
downloading from http://cdimage.ubuntu.com/ubuntu-server/daily/current/bionic-server-amd64.iso:
#################### 100.0% 20540.8 kBps DONE

verifying download…checksum matches OK

@kubiko Output from snap changes and snap change below, syslog output (with snapd debugging enabled) attached here.

root@battra:~# snap changes
ID   Status  Spawn                 Ready                 Summary
30   Error   2018-02-22T09:55:45Z  2018-02-22T10:02:02Z  Install "wekan" snap from "edge" channel
31   Error   2018-02-22T10:27:51Z  2018-02-22T10:33:04Z  Install "wekan" snap from file "wekan_0.76-22-g31f25bc_amd64.snap"
32   Error   2018-02-22T12:05:21Z  2018-02-22T12:10:33Z  Install "wekan" snap from file "wekan_0.76-22-g31f25bc-dirty_amd64.snap"
33   Error   2018-02-22T12:12:20Z  2018-02-22T12:17:32Z  Install "wekan" snap from file "wekan_0.76-22-g31f25bc-dirty_amd64.snap"
34   Error   2018-02-22T12:25:15Z  2018-02-22T12:30:28Z  Install "wekan" snap from file "wekan_0.76-22-g31f25bc-dirty_amd64.snap"
35   Error   2018-02-22T15:28:37Z  2018-02-22T15:33:54Z  Install "wekan" snap
36   Error   2018-02-23T06:24:32Z  2018-02-23T06:31:05Z  Install "wekan" snap

root@battra:~# snap change 36
Status  Spawn                 Ready                 Summary
Done    2018-02-23T06:24:32Z  2018-02-23T06:31:05Z  Ensure prerequisites for "wekan" are available
Undone  2018-02-23T06:24:32Z  2018-02-23T06:31:05Z  Download snap "wekan" (128) from channel "stable"
Done    2018-02-23T06:24:32Z  2018-02-23T06:31:04Z  Fetch and check assertions for snap "wekan" (128)
Undone  2018-02-23T06:24:32Z  2018-02-23T06:31:04Z  Mount snap "wekan" (128)
Undone  2018-02-23T06:24:32Z  2018-02-23T06:31:03Z  Copy snap "wekan" data
Undone  2018-02-23T06:24:32Z  2018-02-23T06:31:03Z  Setup snap "wekan" (128) security profiles
Undone  2018-02-23T06:24:32Z  2018-02-23T06:31:02Z  Make snap "wekan" (128) available to the system
Undone  2018-02-23T06:24:32Z  2018-02-23T06:31:01Z  Set automatic aliases for snap "wekan"
Undone  2018-02-23T06:24:32Z  2018-02-23T06:31:01Z  Setup snap "wekan" aliases
Done    2018-02-23T06:24:32Z  2018-02-23T06:31:01Z  Run install hook of "wekan" snap if present
Undone  2018-02-23T06:24:32Z  2018-02-23T06:31:01Z  Start snap "wekan" (128) services
Error   2018-02-23T06:24:32Z  2018-02-23T06:31:00Z  Run configure hook of "wekan" snap if present

......................................................................
Run configure hook of "wekan" snap if present

2018-02-23T08:31:00+02:00 ERROR run hook "configure": <exceeded maximum runtime of 5m0s>

@kubiko Thanks for taking a look!

I have two systems affected by this, both running Ubuntu 16.04[.3] LTS desktop and both tracking the core snap, with the following specifics:

Server (though with Ubuntu desktop installed)

This system is running stock 16.04 (no -proposed or HW) and Apache doing proxying. I had previously installed the snap on this system, set my root-url and changed the port to 3333 (IIRC), and it was running fine when the issue occurred sometime around the January 15th refresh. I’ve since removed the snap along with the settings so the attempts on this system should in theory be clean installs.

17.33 jani@battra:~$ uname -a
Linux battra 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
17.33 jani@battra:~$ snap version
snap    2.31
snapd   2.31
series  16
ubuntu  16.04
kernel  4.4.0-112-generic
17.33 jani@battra:~$ snap info core
name:      core
summary:   snapd runtime environment
publisher: canonical
contact:   snappy-canonical-storeaccount@canonical.com
license:   unknown
description: |
  The core runtime environment for snapd
type:        core
snap-id:     99T7MUlRhtI3U0QFgl5mXXESAiSwt776
tracking:    stable
installed:   16-2.31 (4017) 85MB core
refreshed:   2018-02-06 17:18:04 +0200 EET
channels:                                  
  stable:    16-2.31                (4017) 85MB -
  candidate: 16-2.31.1              (4110) 85MB -
  beta:      16-2.31.1              (4110) 85MB -
  edge:      16-2.31+git586.d89ba3c (4127) 85MB -
17.34 jani@battra:~$ snap list
Name  Version  Rev   Developer  Notes
core  16-2.31  4017  canonical  core

Main desktop

This system has the -proposed repository enabled and the HWE stack installed, no proxy. I’ve only ever attempted to install Wekan on this system after the issue occurred on the other system, and it has never succeeded (so in that sense it’s a clean install… attempt anyway).

17.08 jani@saegusa:~$ uname -a
Linux saegusa 4.13.0-36-generic #40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
17.11 jani@saegusa:~$ snap version
snap    2.31.1
snapd   2.31.1
series  16
ubuntu  16.04
kernel  4.13.0-36-generic
17.11 jani@saegusa:~$ snap info core
name:      core
summary:   snapd runtime environment
publisher: canonical
contact:   snappy-canonical-storeaccount@canonical.com
license:   unknown
description: |
  The core runtime environment for snapd
type:        core
snap-id:     99T7MUlRhtI3U0QFgl5mXXESAiSwt776
tracking:    stable
installed:   16-2.31 (4017) 85MB core
refreshed:   2018-02-06 17:18:04 +0200 EET
channels:                                  
  stable:    16-2.31                (4017) 85MB -
  candidate: 16-2.31.1              (4110) 85MB -
  beta:      16-2.31.1              (4110) 85MB -
  edge:      16-2.31+git586.d89ba3c (4127) 85MB -
17.12 jani@saegusa:~$ snap list
Name  Version  Rev   Developer  Notes
core  16-2.31  4017  canonical  core

Since the issue with Wekan occurred, I’ve tried installing other snaps (on both systems) and they all work just fine.

If there’s anything else you need or something I missed, please let me know and I’ll be happy to provide.

I’m fairly sure it’s a matter of some configuration these two systems happen to have, and the Wekan snap issue is mainly just that of it not failing gracefully under the circumstances and leaving me in the dark about the exact cause.