Possible upstream issues: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842015 -> https://dev.gnupg.org/T2818 (-> https://dev.gnupg.org/T2843#)

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,.

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

Alright, thanks Jamie!

Output of `snap interfaces` during `snap install wekan` Edit (2.4 KiB, text/plain)

The Apparmor denial seems to no longer occur with 2.31.1.

`snap interfaces` lists ’wekan’ connected to network and network-bind, but not hardware-observe. I’m struggling with the correct syntax for manually connecting it to anything:

root@saegusa:~# snap connect wekan :hardware-observe
error: cannot resolve connection, plug snap name is empty
root@saegusa:~# snap connect wekan:wekan :hardware-observe
error: snap ”wekan” has no plug named ”wekan”
root@saegusa:~# snap connect wekan: :hardware-observe
error: invalid value: ”wekan:” (want snap:name or snap)
root@saegusa:~# snap connect :wekan :hardware-observe
error: cannot resolve connection, plug snap name is empty

`snap interfaces` does list a ’wekan:mongodb-plug’, which (if I’m reading the output right) is unattached. Attempting to connect that to hardware observe:

root@saegusa:~# snap connect wekan:mongodb-plug :hardware-observe
error: cannot connect wekan:mongodb-plug (”content” interface) to core:hardware-observe
(”hardware-observe” interface)

There’s also a ’wekan:mongodb-slot’. Attempting to connect mongodb-plug to that:

root@saegusa:~# snap connect wekan:mongodb-plug wekan:mongodb-slot
error: snap ”wekan” has ”install-snap” change in progress

That’s true, since I’m only able to see those two during the time that the installation is stuck.

I’ll attach the full output of `snap interfaces` below. It’s the same output that `snap interfaces` produces on the VM without the issue (after installation, when the service is running).

As for the other question, there are wekan-related commands running when it’s stuck (listing below). The service seems to be up and running already (I can open it in a browser) for the time it remains in the configuration phase, but when the hook times out it of course gets cancelled and the installation is undone.

root@saegusa:~# ps aux | grep wekan
root 10517 1.2 0.1 935608 23360 pts/22 Sl+ 17:45 0:00 snap install wekan
root 10782 0.0 0.0 18056 2760 ? Ss 17:45 0:00 /bin/bash /snap/wekan/124/bin/mongodb-control
root 10809 4.4 0.3 283812 54748 ? Sl 17:45 0:01 mongod –dbpath /var/snap/wekan/common –logpath /var/snap/wekan/common/mongodb.log –logappend –journal –unixSocketPrefix /var/snap/wekan/124/share –port 27019
root 10811 0.0 0.0 18052 2892 ? S 17:45 0:00 /bin/bash /snap/wekan/124/meta/hooks/configure
root 10871 0.0 0.0 18056 2676 ? Ss 17:45 0:00 /bin/bash /snap/wekan/124/bin/wekan-control
root 10898 7.6 0.6 1172036 103648 ? Sl 17:45 0:02 /snap/wekan/124/bin/node main.js
root 10975 0.0 0.0 15464 1012 pts/23 S+ 17:46 0:00 grep –color=auto wekan

Update: got snapd 2.31.1 from -proposed this morning, and replaced the customized /etc/apparmor.d/usr.lib.snapd.snap-confine.real with the package-provided version. This did not fix the issue unfortunately.

Since some time over the holidays I’ve had problems refreshing/installing the Wekan snap [1] on my home server and also my desktop. The installation stalls at the configuration phase, which on the surface looks a bit like bug #1674193 [2], but here core gets installed just fine, and the hang occurs just alike if I first install just core, then the `wekan` snap separately.

14.52 jani@saegusa:~$ sudo snap install wekan
[sudo] salasana henkilölle jani:
error: cannot perform the following tasks:
– Run configure hook of ”wekan” snap if present (run hook ”configure”: <exceeded maximum runtime of 5m0s>)

Installing other snaps works (the couple that I tried just to be able to say this did anyway).

I’ve reported this on the Wekan snap Github page [3], but there’s been no confirmation from anyone else affected so far. Also, I’m unable to reproduce this myself in a VM and on at least one other (physical) desktop I have access to.

So naturally I’ve looked for differences between these systems, but so far the only correlating one I’m pretty sure of is an Apparmor denial:

apparmor=”DENIED” operation=”open” profile=”snap.wekan.mongodb” name=”/sys/block/” pid=9478 comm=”mongod” requested_mask=”r” denied_mask=”r” fsuid=0 ouid=0

The two systems where Apparmor denies mongodb’s access to /sys/block get stuck at the configure hook, whereas systems that don’t deny access finish the configuration (and installation) successfully.

I have not tweaked any Apparmor configuration on any of these systems prior to this issue cropping up (not that I can remember anyway). I’ve also not touched anything snap-related, as Wekan was one of the first snaps I’ve ever tried and is (or would be) the only one (besides core) currently installed on these systems.

All systems are running Ubuntu 16.04, with my (affected) desktop having both HWE and -proposed enabled, my (affected) server running a 4.4-series kernel (no HWE or -proposed) and the other (unaffected) desktop having HWE but no -proposed. The (unaffected) VM starts with kernel 4.4 and remains unaffected if I upgrade it with HWE.

I’m submitting this from the (HWE+proposed-enabled) desktop, so any logs attached here are from one of the two affected systems. I’ll of course provide other logs too if requested.

* [1] https://snapcraft.io/wekan/
* [2] https://bugs.launchpad.net/snappy/+bug/1674193
* [3] https://github.com/wekan/wekan-snap/issues/25

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: snapd 2.29.4.2
ProcVersionSignature: Ubuntu 4.13.0-30.33~16.04.1-generic 4.13.13
Uname: Linux 4.13.0-30-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.15
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Jan 22 15:44:20 2018
InstallationDate: Installed on 2016-10-13 (466 days ago)
InstallationMedia: Ubuntu-Server 16.04.1 LTS ”Xenial Xerus” – Release amd64 (20160719)
SourcePackage: snapd
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.X11.Xsession.d.65snappy: 2018-01-19T18:18:12.001969
mtime.conffile..etc.apparmor.d.usr.lib.snapd.snap-confine.real: 2018-01-22T15:46:34.793893

After upgrading to Quantum, the right mouse button context menu for HTML links pops up in the wrong place when the Firefox window is pushed to either side of my screen (so that the window takes up half of the horizontal space). The issue appears similar to what has been reported in bug #1721614 (particularly as it appears in the video attached by the submitter), but for me the issue does not occur with the hamburger menu or other UI elements, only with links on webpages, and the menu highlighting behavior is different: in my issue the highlighting occurs normally only once I point the cursor at the menu.

== Steps to reproduce ==
1. Create a new profile and start Firefox using the profile.
2. Expand the window to fill the screen (if not already).
3. Enter search terms into the URL bar and hit enter to bring up a search results page.
4. Right-click a search result title to bring up the context menu. Left-click outside it to close it.
5. Grab the window title bar and push the window to the right edge of screen to resize the window to span half of screen horizontally. Release the title bar.
4. Right click the search result title again.

== What happens ==
The menu pops up on way off from where the mouse cursor is. See attached screenshot.

== What should happen ==
The context menu should pop up next to mouse cursor.

== Possible culprit ==
This seems to be somehow tied to localization: if I uninstall firefox-locale-*, then create a new Firefox profile, with this new profile the menu pops up where it should. I’m using Finnish locale, but this is reproducible with just firefox-local-en too, although the mispositioning differs between locales (Finnish pushes the menu off to the left, whereas English pushes it down and to the right).

== Workaround ==
Don’t right-click on the page before resizing the window (that is, skip step #4 above). This seems to be the trigger.

== Other info ==
I’m able reproduce this in a (16.04) VM just as well as on the host desktop.

In case the collected data doesn’t include this, my primary display is 2560 × 1440p, and the only display connected. xrandr output:

Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 8192 x 8192
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 connected primary 2560×1440+0+0 (normal left inverted right x axis y axis) 527mm x 296mm
2560×1440 59.95*+
2048×1152 59.90
1920×1200 59.88
1920×1080 60.00 50.00 59.94 24.00 23.98
1920x1080i 60.00 50.00 59.94
1600×1200 60.00
1680×1050 59.95
1280×1024 75.02 60.02
1280×800 59.81
1152×864 75.00
1280×720 60.00 50.00 59.94
1024×768 75.03 60.00
800×600 75.00 60.32
720×576 50.00
720×480 60.00 59.94
640×480 75.00 60.00 59.94
720×400 70.08
HDMI-2 disconnected (normal left inverted right x axis y axis)
HDMI-3 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)

Screenshot with the context menu off to the left of mouse cursor (Finnish locale) Edit (490.3 KiB, image/png)