Bug #11038
pinentry and gnome shell's top bar cause freeze
100%
Description
While pinentry is running, attempting to start a program (e.g. keepassx) via gnome shell’s top bar causes all windows to freeze. This includes the pinentry window, which makes it impossible to click the close button. The pinentry still grabs the keyboard, so the only way to fix this from within the gnome session seems to be to enter the correct password or entering wrong passwords three times, which causes the pinentry window to close.
Subtasks
Related issues
Related to Tails - |
Rejected | 2015-06-10 | |
Related to Tails - |
Resolved | 2016-02-09 |
History
#1 Updated by sajolida 2016-02-01 13:22:45
- Assignee set to segfault
- QA Check set to Ready for QA
Maybe we’re talking about slightly different things but when I do:
- Open KeeyPassX.
- Click on an encrypted email in Icedove and get the pinentry prompt.
- Click on the KeyPassP top icon.
- Then KeePassX opens and I can right-click and do Perform AutoType.
Are you doing something different?
#2 Updated by segfault 2016-02-01 13:35:27
I mean starting it via the application menu, not displaying the window via the icon (which is only present if it was already started). I wrote “top bar” instead of “application menu” because I noticed that this also happens if you open the settings from the top right menu. But I see that this is an ambiguous wording.
#3 Updated by intrigeri 2016-02-02 12:49:50
- related to
Feature #9555: Include a pinentry GUI that's well integrated within GNOME added
#4 Updated by intrigeri 2016-02-02 12:51:01
- QA Check changed from Ready for QA to Info Needed
Did this work fine on Tails 1.8.2?
I suspect that this integration problem would be fixed if we did Feature #9555. segfault, would you be interested in working on that?
#5 Updated by sajolida 2016-02-02 15:20:07
Now I see what you mean. It’s not really freezing but behaving weirdly and impossible to open KeePassX for sure. That’s bad!
#6 Updated by segfault 2016-02-02 15:27:14
This is fixed in the pinentry versions in debian testing. See my post on Feature #9555.
#7 Updated by intrigeri 2016-02-04 20:11:08
Woo! If you think you can get it fixed in 2.2, please set “Target version” accordingly :)
#8 Updated by segfault 2016-02-09 15:34:09
In subsequent tests I did while working on Feature #9555, this bug reappeared even in the pinentry-gtk2
package from debian testing. I filed a bug in the gnupg bug tracking system: https://bugs.gnupg.org/gnupg/issue2248
#9 Updated by segfault 2016-02-09 21:16:25
- related to
Bug #11099: Decide which pinentry we want to ship added
#10 Updated by segfault 2016-02-20 15:12:21
I stated this on Bug #11099 but forgot to mention it here:
Either using pinentry-gnome3
or adding no-grab
to gpg-agent.conf
fixes this bug.
#11 Updated by segfault 2016-02-20 15:13:40
- QA Check deleted (
Info Needed) - Type of work changed from Code to Discuss
#12 Updated by segfault 2016-03-09 22:56:58
We decided in the monthly meeting to use the —no-global-grab option to fix this bug. I’m preparing a commit.
#13 Updated by segfault 2016-03-09 23:34:58
- Status changed from New to In Progress
- Assignee deleted (
segfault) - Target version set to Tails_2.4
- QA Check set to Ready for QA
- Feature Branch set to segfault:bugfix/11038-pinentry-no-global-grab
- Type of work changed from Discuss to Code
I pushed a branch with a commit which simply adds no-global-grab
to .gnupg/gpg-agent.conf
:
https://gitlab.com/segfault_/tails/commits/bugfix/11038-pinentry-no-global-grab
#14 Updated by segfault 2016-03-20 11:01:00
- Target version changed from Tails_2.4 to Tails_2.3
> I pushed a branch with a commit which simply adds no-global-grab to .gnupg/gpg-agent.conf:
> https://gitlab.com/segfault_/tails/commits/bugfix/11038-pinentry-no-global-grab
Oops, I forgot I already linked to this here. I noticed I used the wrong option name (the pinentry option is named ‘no-global-grab’ but the gpg-agent option is ‘no-grab’) and now force pushed the amended commit.
If you already pulled this, please redo it.
Btw, the invalid option in gpg-agent.conf caused a greeter loop, i.e. the X session crashs right after the greeter.
#15 Updated by anonym 2016-04-25 07:13:59
- Status changed from In Progress to Fix committed
- % Done changed from 0 to 100
Applied in changeset commit:f54f8f935d2465256fe1f153c4248533d8250db8.
#16 Updated by anonym 2016-04-26 09:13:29
- Status changed from Fix committed to Resolved
#17 Updated by intrigeri 2018-04-08 16:47:25
- QA Check deleted (
Ready for QA)