Project

General

Profile

Feature #9555

Include a pinentry GUI that's well integrated within GNOME

Added by intrigeri over 4 years ago. Updated almost 4 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
06/10/2015
Due date:
% Done:

10%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

For various reasons (#5931, #5419) we've moved from GNOME's own implementation of a GnuPG agent to the regular gnupg-agent + pinentry-gtk2. Sadly, the latter is badly integrated in GNOME. The good news is that GNOME will drop its own implementation of the agent, and instead a nicer pinentry GUI is being developed:

It's called pinentry-gnome3 and is already available in Debian sid. For Tails/Jessie, we should consider replacing pinentry-gtk2 with that one :)


Related issues

Related to Tails - Bug #11038: pinentry and gnome shell's top bar cause freeze Resolved 02/01/2016
Related to Tails - Bug #8121: Consider disabling KeePassX' autotype feature Resolved 10/14/2014
Related to Tails - Feature #6020: pinentry vs. paste Resolved
Related to Tails - Bug #11099: Decide which pinentry we want to ship Resolved 02/09/2016
Related to Tails - Bug #11188: GNOME Shell sometimes crashes and restarts Confirmed 03/03/2016
Related to Tails - Bug #12733: Seahorse fails to import private PGP keys: pinentry-gtk-2 passphrase prompt not displayed Resolved 06/19/2017

History

#1 Updated by intrigeri over 4 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

pinentry-gnome3 from testing (0.9.4-2) installs just fine on current feature/jessie. It seems to work fine at first glance. It indeed is better integrated, graphically speaking, into the desktop. But strangely, it doesn't do the fancy "cover the rest of the desktop with some partially opaque overlay" thing I see on my Debian sid, and is gray instead of black.

#2 Updated by intrigeri about 4 years ago

  • Priority changed from Low to Normal
  • Target version deleted (Tails_2.0)

intrigeri wrote:

pinentry-gnome3 from testing (0.9.4-2) installs just fine on current feature/jessie.

This is not the case anymore, it'll require a backport. Removing it from the list of potential blockers for 2.0, but bumping priority since it would be a nice UX improvement. Any taker?

#3 Updated by intrigeri almost 4 years ago

  • Related to Bug #11038: pinentry and gnome shell's top bar cause freeze added

#4 Updated by segfault almost 4 years ago

I just tried the pinentry-gnome3. It looks nice (although it says "_Cancel" and "_Ok" on the buttons). In difference to pinentry it allows pasting, which I like a lot, because it doesn't require keepassx' autotype. BUT it disables focussing any other windows, which breaks usability with keepassx, because you can't copy your passphrase when being prompted for it.

I think a lot of users use keepassx. So I'm not happy with pinentry-gnome3. But the current pinentry-gtk-2 sucks too, because it requires autotype, which is a pain for users (especially if you set their email address as the user name in the keepassx entry, because then it will type the user name AND the password - which is, of course, not what gpg expects).

In previous Tails versions, a workaround for this was disabling the gpg-agent in gpg.conf, which caused enigmail to use a password prompt which allowed focussing other windows and pasting. But this doesn't work with gpg2, which is the default now. I'm still looking for a user friendly option that works with gpg2.

#5 Updated by segfault almost 4 years ago

  • Type of work changed from Code to Discuss

#6 Updated by segfault almost 4 years ago

  • Type of work changed from Discuss to Research

#7 Updated by segfault almost 4 years ago

  • Assignee set to segfault
  • Type of work changed from Research to Discuss

The not-being-able-to-paste issue is fixed in pinentry 0.8.4:
https://bugs.launchpad.net/ubuntu/+source/pinentry/+bug/326132/comments/20
Debian jessie packages pinentry-gtk2 0.8.3-2. Using the one from debian testing (0.9.7-1) fixes this. So it allows pasting and focussing other windows, which makes it usable in conjunction with KeePassX. It also fixes #11038. So I vote for using pinentry-gtk2 from testing instead of pinentry-gnome3. Discuss?

#8 Updated by segfault almost 4 years ago

  • Related to Bug #8121: Consider disabling KeePassX' autotype feature added

#9 Updated by segfault almost 4 years ago

#10 Updated by muri almost 4 years ago

  • Type of work changed from Discuss to Code

setting type of work to code, segfault offered in the meeting to do a branch

#11 Updated by intrigeri almost 4 years ago

I might have missed something, but IMO upgrading pinentry-gtk2 does not give us "a pinentry GUI that's well integrated within GNOME".

I'm glad if it solves other problems, though :) ... but then this is off-topic on this ticket.

#12 Updated by intrigeri almost 4 years ago

I just tried the pinentry-gnome3. It looks nice (although it says "_Cancel" and "_Ok" on the buttons). In difference to pinentry it allows pasting, which I like a lot, because it doesn't require keepassx' autotype. BUT it disables focussing any other windows, which breaks usability with keepassx, because you can't copy your passphrase when being prompted for it.

My guts feeling is that the "stealing focus" behaviour is probably a security feature that we want more than the ability to use KeePassX to input OpenPGP passphrases. I'm sorry I have no time to research this further and elaborate myself on short notice.

I suspect that dkg (now Cc'ed on this bug report) will be able to explain off the top of his head why we want GnuPG pinentry software that steals keyboard and mouse focus. Daniel?

#13 Updated by dkg almost 4 years ago

intrigeri wrote:

I suspect that dkg (now Cc'ed on this bug report) will be able to explain off the top of his head why we want GnuPG pinentry software that steals keyboard and mouse focus. Daniel?

sure. there are two reasons i can think of immediately (there might be more):

  • grabbing the keyboard makes it so that you can't accidentally send password keypresses to backgrounded windows (we've all seen pastes into IRC, for example) -- if the pinentry is present, and you're typing a password, it won't let you do that by accident.
  • properly grabbing the keyboard (see XGrabKeyboard(3)) is intended to also prevent malicious fellow X11 clients from trying to sniff your keypresses.

That said, I'm more confident in the former rationale than the latter. X11 is old and sprawling, and there might ways around an XGrabKeyboard that i'm unaware of (or possibly just bugs). furthermore, truly malicious tools could just mimic the look of pinentry themselves and if they get the timing right, they can grab the keyboard and do the same thing, leaving the user with no effective way to tell whether this pinentry is a "good" or a "bad" one.

#14 Updated by intrigeri almost 4 years ago

sure. there are two reasons i can think of immediately (there might be more):

Thanks! Any reason for grabbing the mouse focus?

#15 Updated by dkg almost 4 years ago

intrigeri wrote:

Thanks! Any reason for grabbing the mouse focus?

it seems less convincing to me, but there are still some mild arguments.

For focus-follows-mouse setups, it's a little bit strange to grab the kbd, but allow the mouse to re-focus other windows that now can't get any keyboard input.

also, if the practice is to use the mouse to paste a passphrase (e.g. with middleclick), then grabbing the mouse would prevent you from accidentally pasting the password into the wrong window (like your IRC client).

#16 Updated by intrigeri almost 4 years ago

For focus-follows-mouse setups, it's a little bit strange to grab the kbd, but allow the mouse to re-focus other windows that now can't get any keyboard input.

We don't default on focus-follows-mouse so indeed this one is pretty weak in the context of Tails.

also, if the practice is to use the mouse to paste a passphrase (e.g. with middleclick), then grabbing the mouse would prevent you from accidentally pasting the password into the wrong window (like your IRC client).

segfault: can this possibly apply to the KeePassX + pinentry workflow you were keen on supporting? If that workflow is affected by this problem, then IMO it is quite a good reason to steal mouse focus (possibly with pinentry-gnome3) and prevent a dangerous workflow from being used.

Meta: I easily admit I don't take into account all the bits of the big picture that I'm aware of. E.g. KeePassX arguably allows users to use stronger passphrases (but perhaps it's just overkill compared to good passphrases that one can reasonably memorize and type, for 99% of users who will only use very few such passphrases).

#17 Updated by sajolida almost 4 years ago

What segfault is proposing solves #11038. We're here because he started
testing pinentry-gnome3 in #9555#note-4 and we never split back the
discussion.

#18 Updated by sajolida almost 4 years ago

also, if the practice is to use the mouse to paste a passphrase
(e.g. with middleclick), then grabbing the mouse would prevent you
from accidentally pasting the password into the wrong window (like
your IRC client).

segfault: can this possibly apply to the KeePassX + pinentry workflow
you were keen on supporting? If that workflow is affected by this
problem, then IMO it is quite a good reason to steal mouse focus
(possibly with pinentry-gnome3) and prevent a dangerous workflow
from being used.

I tested this with Tails 2.0 and you can currently copy/paste strings
all over the place even with pinentry displayed using selection and
middle-click.

Still, you can't copy/paste a KeePassX passphrase this way unless it's
made visible first (with the "eye" icon).

My humble opinion is that the UX vs security trade-off is not clear to
me. I'd need to learn more about how bad grabbing the mouse would be,
how much people depend on this, if anything else would be affected, etc.

Meta: I easily admit I don't take into account all the bits of the
big picture that I'm aware of. E.g. KeePassX arguably allows users to
use stronger passphrases (but perhaps it's just overkill compared to
good passphrases that one can reasonably memorize and type, for 99%
of users who will only use very few such passphrases).

I'm not sure to understand you here. Do you mind reformulating?

#19 Updated by segfault almost 4 years ago

I might have missed something, but IMO upgrading pinentry-gtk2 does not give us "a pinentry GUI that's well integrated within GNOME".

I'm glad if it solves other problems, though :) ... but then this is off-topic on this ticket.

I posted #9555#note-4 and #9555#note-7 here because I think we should reject this issue or set it to "wait" because the only pinentry that's well integrated within gnome-shell causes other problems. But maybe there should also be a new issue "pinentry unusable in conjunction with KeePassX", because this is not only about fixing #11038.

also, if the practice is to use the mouse to paste a passphrase (e.g. with middleclick), then grabbing the mouse would prevent you from accidentally pasting the password into the wrong window (like your IRC client).

segfault: can this possibly apply to the KeePassX + pinentry workflow you were keen on supporting? If that workflow is affected by this problem, then IMO it is quite a good reason to steal mouse focus (possibly with pinentry-gnome3) and prevent a dangerous workflow from being used.

EDIT: I misunderstood the question at first.
With pinentry-gtk2 from testing, which grabs the keyboard but not the mouse and allows pasting, it is indeed possible to paste the clipboard into other windows via the middle mouse. Maybe a feature request to disable this could be filed in the gnupg ticket system.

Meta: I easily admit I don't take into account all the bits of the big picture that I'm aware of. E.g. KeePassX arguably allows users to use stronger passphrases (but perhaps it's just overkill compared to good passphrases that one can reasonably memorize and type, for 99% of users who will only use very few such passphrases).

I think we should take this into account. IMO many Tails users use and should use a password manager like KeePassX. So we should not use a pinentry that's horrible to use with KeePassX. I assumed the usefulness of KeePassX was without doubt, because it's been shipped with Tails since 0.17 (3.5 years) and was one of the programs with a launcher in the top panel / shortcut in the "Favorites" menu. I don't think it's overkill but perfect for the use with a contextual identity which should only be used from a secure system.

#20 Updated by segfault almost 4 years ago

Still, you can't copy/paste a KeePassX passphrase this way unless it's
made visible first (with the "eye" icon).

That's actually not true, you can also copy the passphrase with right click and "Copy password to clipboard" or just Ctrl+C (except for this special case where you can't use the keyboard). That's what makes KeePassX usable IMO. Like I stated before, I think the autotype feature is not very user friendly and makes it also more probable to leak the passphrase accidentally, because by default it types enter after typing the passphrase.

#22 Updated by segfault almost 4 years ago

  • Related to Bug #11099: Decide which pinentry we want to ship added

#23 Updated by emmapeel almost 4 years ago

  • Priority changed from Normal to Elevated

This problem makes OpenPGP applet unusable in current Tails 2.2, so I mark it as Elevated because it is a regression.

#24 Updated by intrigeri almost 4 years ago

This problem makes OpenPGP applet unusable in current Tails 2.2,

How so? (We have automated tests for OpenPGP applet, that should ensure it's not "unusable", but of course they don't cover all possible usecases.)

#25 Updated by emmapeel almost 4 years ago

intrigeri wrote:

This problem makes OpenPGP applet unusable in current Tails 2.2,

How so? (We have automated tests for OpenPGP applet, that should ensure it's not "unusable", but of course they don't cover all possible usecases.)

Well if I understood the problem, in cases like:

- Clipboard encryption: you cannot copy the passphrase in or out of the pinentry.
- If I receive such a message and I have a long passphrase, I cannot copy from another window after I have started decryption.

#26 Updated by intrigeri almost 4 years ago

OK, now I understand what you mean with "unusable". Thanks.

#27 Updated by intrigeri almost 4 years ago

  • Related to Bug #11188: GNOME Shell sometimes crashes and restarts added

#28 Updated by segfault almost 4 years ago

  • Assignee deleted (segfault)
  • Priority changed from Elevated to Normal

We decided in #11099 that we currently won't ship a pinentry that's well integrated, because pinentry-gnome3 is unusable with KeePassX.

#29 Updated by intrigeri almost 4 years ago

  • Status changed from In Progress to Rejected

So I guess that "Rejected" expresses this quite clearly.

#30 Updated by intrigeri over 2 years ago

  • Related to Bug #12733: Seahorse fails to import private PGP keys: pinentry-gtk-2 passphrase prompt not displayed added

Also available in: Atom PDF