Fixed in

Ready for implementation by Andre.

Thanks for your feedback.
I was wondering specifically about the use-case when you want to enter
and "ok" the passphrase. The regular flow for this as I understand it would=
be

  typing the passphrase and then "enter" or "return"

I think it is okay to have "tab" cycle between options, but including the=20
option of toggling visibility, because somebody who want to enter the=20
passphrase would (in my understand) always do the above flow and not=20
tab-tab-enter.

FWIW, with commit 19545e3a from 2015-09-09 I had bumped the limit up to 20MiB.
This should solve all current practical problems.

pinentry-gtk-2 does currently support the tab-tab-enter use case. Using 0.9.6-4
from debian, i can use tab to cycle between the textentry dialog and cancel and OK.

I see the same behavior from pinentry-gnome3 (0.9.6-4), tab workflow is:

• textentry
• Cancel
• OK

for pinentry-qt (same version as tested above) the tab ordering is:

• textentry
• OK
• Cancel

That said, i agree that i'm the only person who has raised this, and i'm
perfectly willing to be retrained to use more efficient keyboard flows if
they're presented to me. So if you want to go ahead with the current plan,
that's fine with me.

I agree that consistency with common UI patterns on the platform of choice are
worth emulating -- we don't need to invent or maintain our own UI patterns that
are idiosyncratic to GnuPG.

(2nd try, the mailinterface failed for me.)

http://www.aelog.org/password-visibility-in-kpassworddialog/

Good that you found it.
In the comments Bogdan has a point.
The screenshots also do not look convincing, but I agree it makes sense to be
consistent there. Could we also get a screenshot about this implementation
for Windows 8 they are talking about?

For GTK we should implement it the way werner has outlined and as has been
discussed on the mailing list. So that users with more "Keyboard centric"
workflow have the GTK alternative available.

As gtk-pinentry

1. currently does not allow tab-return
2. and it does not make sense as a workflow
3. we are lacking further evidence if there are users that still use this for a password entry. (Not response by dkg.)

I'd say the discussion on the mailinglist is fully superceded.

In my view we should
a) design it close to pinentry-qt, because it also will be used on Windows

mostly and the consistency with other Windows password dialogs has a lot of 
weight

b) Look at other wide spread gtk-dialog for this functionality and use

   the better design considerin Bogdans comment with a "switch".

The icon could possibly used in both implementations. (If the license allows
this. Oxygen used to have a bit less practical licene coming with it.)

Best,
Bernhar

Bernhard:

I've tried out KDE 5 and noticed that the standard password dialog there already
has such an option. http://www.aelog.org/password-visibility-in-kpassworddialog/

My strong preference for Pinentry-qt would be to make it similar. As a unified
UI adds value and pinentry-qt is afail most often used with Windows and KDE
desktops. And the solution outlined in the link above is also very similar to
the Windows 10 password entry.

For GTK we should implement it the way werner has outlined and as has been
discussed on the mailing list. So that users with more "Keyboard centric"
workflow have the GTK alternative available.

Would this be acceptable for you?

Please run

  gpg --with-keygrip --with-fingerprint --with-fingerprint -K 30A99F9A

and

  gpg --with-keygrip --with-fingerprint --with-fingerprint -K 9BA84708

If one of the commands does not show a key run it again with -k
(lowercase). Also run

gpg --version

Werner notes:

There is a comment in mainproc that we need to sort the list of keys and try
them in an order to get a decryption key early. The other thing is about the
meta data for keys. It would be possible to add a priority to the private keys
and use them to prioritise the list of keys to try.

@dkg,
what do you think about T2139 (bernhard on Nov 02 2015, 10:09 AM / Roundup)?

As an additional point, the client max body size in nginx defaults to 1 MiB[0].
Currently no checking is done for larger request bodies for inclusion in the
keyserver pools. Apache does not have such a limit by default.

Reference:
[0] http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

Kristian Fiskerstrand told me that the SKS keyservers currently have a 5 MB
limit for parsing incoming header, pre-merge.

Fixed in 1e3dbb15.

It looks like this problem has been fixed in the meantime. As such, I'm marking
this bug as resolved. Thanks.

$ gpg2 --with-fingerprint 4F43C989.txt
pub rsa1024/4F43C989 2015-11-17

Key fingerprint = A8D8 E9B9 D25D 6AB8 9997  AEE4 3817 872D 4F43 C989

uid Testing <testing@testing.com>
sub rsa1024/3CAD33EE 2015-11-17
sub rsa1024/FE39BBA1 2015-11-17
sub elg1024/A10351BD 2015-11-17
$ gpg2 --fingerprint 4F43C989
pub rsa1024/4F43C989 2015-11-17

Key fingerprint = A8D8 E9B9 D25D 6AB8 9997  AEE4 3817 872D 4F43 C989

uid [ unknown] Testing <testing@testing.com>
sub rsa1024/3CAD33EE 2015-11-17
sub rsa1024/FE39BBA1 2015-11-17
sub elg1024/A10351BD 2015-11-17

Committed (ec409e6).

Verifying the unwrapped data also works:

$ gpg2 --decrypt --unwrap /tmp/a > /tmp/b
Please enter the passphrase to unlock the OpenPGP secret key:
"Testing (insecure!)"
1024-bit RSA key, ID 6EA74366,
created 2015-09-18 (main key ID EE37CF96).

Passphrase:
gpg: encrypted with 1024-bit RSA key, ID 6EA74366, created 2015-09-18

"Testing (insecure!)"

$ gpg2 --verify /tmp/b
gpg: Signature made Wed 04 Nov 2015 01:53:31 PM CET using RSA key ID EE37CF96
gpg: Good signature from "Testing (insecure!)" [full]
gpg: Verified 7 messages signed by "Testing (insecure!)" (key: 362D 3527 F53A
AD19 71AA FDE6 5885 9975 EE37 CF96, policy: good) in the past 1 day, 20 hours.
The most recent message was verified 22 hours, 40 minutes ago.

D89: 708_0002-gpg-Add-support-for-unwrapping-the-outer-level-of-en.patch

D90: 707_0001-common-Add-a-function-for-copying-data-from-one-iobu.patch

This implements the requested --unwrap feature. It strips the first level of
encryption and then dumps the data.

$ gpg2 --decrypt --unwrap /tmp/a | gpg2 --list-packets
Please enter the passphrase to unlock the OpenPGP secret key:
"Testing (insecure!)"
1024-bit RSA key, ID 6EA74366,
created 2015-09-18 (main key ID EE37CF96).

Passphrase:
gpg: encrypted with 1024-bit RSA key, ID 6EA74366, created 2015-09-18

"Testing (insecure!)"

off=0 ctb=a3 tag=8 hlen=1 plen=0 indeterminate

:compressed packet: algo=2

off=2 ctb=90 tag=4 hlen=2 plen=13

:onepass_sig packet: keyid 58859975EE37CF96
version 3, sigclass 0x00, digest 8, pubkey 1, last=1

off=17 ctb=cb tag=11 hlen=2 plen=13 new-ctb

:literal data packet:
mode b (62), created 1446641593, name="",
raw data: 7 bytes

off=32 ctb=88 tag=2 hlen=2 plen=156

:signature packet: algo 1, keyid 58859975EE37CF96
version 4, created 1446641611, md5len 0, sigclass 0x00
digest algo 8, begin of digest b7 8a
hashed subpkt 2 len 4 (sig created 2015-11-04)
subpkt 16 len 8 (issuer key ID 58859975EE37CF96)
data: [1023 bits]

Hi!

@dkg:
Can you tell me more about your tab-return use case? Do you have hints/personal
observations about how many people are affected?
In the gtk2 pinentry this did not work so far (See my T2139 (bernhard on Oct 29 2015, 04:42 PM / Roundup)) other
implementation do not seem to allow it (I've also tested kdm login screen)
and it does not make much sense either when you can press "return" right away.
So to me it is still unclear how many people are affected.

@aheinecke: Thanks for contributing another case.
I think it is a good solution for a system login screen, where a login-change
probably is harder to do.
I think this slightly changes when you think about passphrases for pinentry
that may get entered less often and some people keep a backup on paper (which is
actually good under some circumstances) and I would claim that a passphrase
change on a key on average is easier to do than a system password.

@werner: You wrote that you've checked some other implementation, it would be cool
to have a list of those. Screenshots would be even better.

@all, my current design ideas are

• to have a text below the entry field, close to it, saying "show password" and a on-off switch or second best a check-box, third best a button.

Rationale: Because the space requirement is mainly in width. An on-off switch

probably has the most natural mapping, but this depend on the overal GUI design
of the system. On some a real slider-switch may not be available or look alien,
then we should use what ever users will recognise as an on-off thing.
The text is much less work than to select/design an icon and it uses
less height.

• It is okay to have that in the accessibility tab list, even after the entry field, because I personally believe that a lot more people want the natural order when using tab at all. Right now the data for how many people actually have the tab-enter habit is unknown, maybe Daniel can help us out here.

Btw. The Windows 10 login screen implements this as a button that you can not
tab to and only shows the password for as long as you keep clicking it.
It also disables / hides the show password button once the password entry field
loses input focus.

They use a heavily abstracted eye icon and no tooltip. Probably with the
rationale that if a user clicks there and it shows the password
(unintentionally) he can quickly release the mouse button again before someone
can read the password.

On Thu 2015-10-29 04:34:03 -0400, Bernhard Reiter via BTS wrote:

@dkg: I have been thinking about your use case:

I wonder about what fraction of people we are speaking of.
In many applications, just like pinentry, you can just hit "enter" right away
so there is no need to first hit "tab". First hitting "tab" does not make sense
for these kind of dialoges.

Then in some implementation like pinentry-gtk2 0.8.3-2,
this does not work right now, because the next tab is "cancel" which users then
would reach. So it depends on the standard for dialog windows where the
ok and cancel buttons are. Was there any problem report on pinentry-gtk-2?
I am not sure if any pinentry-gtk-2 user actually had this problem?

Daniel:
Thanks for your comment and adding the use case. I saw your suggestions
on the list like changing the tab order.

More specifically: Would it be fine with you to implement this without
a warning dialog that requires another click or attention?

Some people are used to pinentry and have a common keyboard-based type, tab, hit
enter workflow.

Please make sure that this workflow doesn't accidentally switch their password
to visible when this change is implemented.

My suggestion is also, to seek for an icon that is more self-explanatory.
Actually I would like the "gtk_switch" gui component, though Werner is right
that it takes up a bit more of space.

Removing and readding key helped. Thanks. Seems to be solved in 2.1.9

Please remove your private key(s) of ed25519 and register it again.

Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798956#24

The same issue in 2.1.9

Applied with commit ea079d2. Thanks.

Haven't seen this problem for months and npth-1.2 contains the fix.

-> Resolved.

Yes only on Windows. Works for me on GNU/Linux, too.

Only on Windows? A quick check on Unix shows that it works.

For no pinentry pop-up, I think that this is same cause described in the Issue 2112.
Please try the patch in T2112

You've actually added code to handle the hostname:port string with rev: 54e55149

But this does not work as the parse_uri check before hat is called with
"no_scheme_check" and so already passes a hostname:port uri as valid and does
not go into the fallback code that adds the http scheme.

D329: 685_0001-Dirmngr-Default-to-http-protocol-for-http-proxy.patch

I use several key of near all types: ed25519, rsa, dsa, ecdsa. All of them have
stopped working.

Regardless of that, I find this is a regression. With my configuration I was
able to search on keyservers with 2.0.x and then with 2.1.x keyserver search no
longer works with the same configuration.

And it's probably easier to default to http protocol for a http-proxy in gnupg /
dirmngr again then it is for me to warn users in Kleopatra / Gpg4win that their
configuration no longer works with 2.1.

Duplicate of T2096

Are you using an Ed25519 key? There was a regression in 2.1.8 which has
meanwhile be fixed in the repo. See also T2096.

Actually I plan to remove (or make them a NOP) all network options from
gpg.conf. This should all be configured in dirmngr.conf.

Forgot to resolve this as superseeded.

With gcrypt compiled with -mstackrealign as analyzed in T2085 this problem
is also fixed.

So I'm marking this as a duplicate of T2085.

Duplicate of T2085

This issue seems fixed in gnupg-w32-2.1.7.

I did not test 2.1 on windows 10 but 2.0 from gpg4win.

Let's consolidate issues though. To simplify things I resolve all reports
regarding this to my report where I will report on debugging / fixing this in
issue2085.

Duplicate of T2085

Duplicate of T2085

Nope not fixed. But let's track this in T2085.

It's not the pinentry. If i install a working pinentry signing files works but
still the migration fails.
Windows Event logs also report that the agent crashed and the process is not
running afterwards.

issue2085 might be related.

Seeing the same on Windows 10 with latest gnupg-w32 package.

Attached is the gpg.log

Migration suceeds from nearly the same homedir under windows 7.

I think the problem is that pinentry-basic does not work on Windows 8.1 and
later. Although I wonder why this should break the migration as I don't get a
pinentry dialog when migrating on Windows 7. (Or on GNU/Linux platforms for that
matter)

Originally dirmngr was a system wide daemon. Thus a limit made a lot of sense
so that users could not oincrease the memory usage of dirmngr. As a user daemon
this is not too problematic anymore but (in contrast to GNU policy), having
limits is still good to avoid DoS. The packet parser also employs certain
limits, like 2K for a user ID or 16M for an attribute packet.

I assume keyservers also have some limit - or at least they should have one to
help against misuse as cheap storage provider. What about using this limit?

can you explain why the limit is useful? e.g. does it increase efficiency in
some metric? defend against certain classes of attack? something else? sorry
that i don't understand the tradeoff fully.

a runtime configuration would be better than a hard fail, but in either case it
seems like we're asking the user to fiddle with things that they shouldn't have
to think about or understand. is there a way that we can automatically detect
the reason for the failure and make things Just Work for normal users without
opening up the tooling to more problems?

Did you reported that at gnupg-users? Let's discuss things in the mail thread.
Andre tested it on Windows 10 so in general it works. The problem must be due
to your local configuration.

Our tests show this works. Thanks!