Tails

#4 Updated by segfault 2016-02-02 13:17:41

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.

#11 Updated by intrigeri 2016-02-04 19:39:18

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 2016-02-04 19:43:09

> 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 2016-02-04 20:09:28

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 2016-02-04 20:35:57

> 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 2016-02-04 20:44:02

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 2016-02-04 21:23:43

> 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 2016-02-05 13:34:24

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

#18 Updated by sajolida 2016-02-05 13:45:38

>> 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 2016-02-09 13:12:41

> 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 Feature #9555#note-4 and Feature #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 Bug #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 2016-02-09 13:18:43

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

#23 Updated by intrigeri 2016-03-13 00:10:03

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

#24 Updated by emmapeel 2016-03-13 09:57:16

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.

#25 Updated by intrigeri 2016-03-13 10:24:10

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