According to Werner's comment, this is not a bug so closing.

Note: T1232 is related.

The warning is in the documentation. I'm closing this.

The main complaint was fixed in 2b27acc and the program was marked as deprecated
in the documentation.

Where should this output be displayed? When doing gpg2 -K, revoked user ids are
not shown. Perhaps in --edit-key? Nevertheless, it would be nice to have a
command line option to get this information directly.

Checked in (e8c53fc).

Werner: This patch is still relevant and it only changes diagnostics so it
shouldn't impact any existing code. Okay to apply?

I can't find any current information about PocketConsole or PocketGnuPG on the
web. I'm assuming that the software is not supported anymore and, as such, I've
removed the link.

With 'wait' I mean: Push, release, wait for complaints.

log_error (_("no such key corresponding to: %s\n"),t->d)
if (!opt.quiet)

  log_info ("(check argument of option '%s')\n", option);

However, we need to check all error messages to make sure they use a common
scheme. For example at some places we use

key 123445567: This is is not usable

• When you say let's wait, what do you mean? In particular, how are we going to

get a user response without checking the code in?

• Ok. I will return an error code.

• I already do this, e.g.:

log_error (_("no such key corresponding to %s (passed to %s)\n"),

t->d, option);

Some comments:

• Always checking this _might_ slow down things. Let's wait for user response.

• Please do not die in that function. We may want to use it a other places too (server mode). Better return an error (NULL) and let the caller decide what to do.

• The strings should be changed to ease translation: For example put the second part into its own message: log_info ("(check argument of option '%s')\n", "--local-user");

D106: 719_0001-gpg-Check-for-ambiguous-or-non-matching-key-specs.patch

The following patch adds checks for --default-key, --local-user and --remote-user.

Check that any user id specifications passed to --local-user
and --remote-user correspond to exactly 1 user. Check that any user
id specifications passed to --default-key correspond to at most 1
user. Warn if any user id specifications passed to --local-user or
--default-user are possible ambiguous (are not specified by long keyid
or fingerprint).

$ gpg2 -s -a -r testing
gpg: WARNING: recipients (-r) given without using public key encryption
gpg: Error: the key specification 'testing' is ambiguous (passed to --encrypt-to).
gpg: 'testing' matches at least: 362D3527F53AAD1971AAFDE658859975EE37CF96 and
439D954F18F79CC4F71BED91CACED996BC15C85A.
$ gpg2 -s -a --local-user testing
gpg: Warning: value 'testing' for --local-user should be a long keyid or a
fingerprint.
gpg: Error: the key specification 'testing' is ambiguous (passed to --local-user).
gpg: 'testing' matches at least: 362D3527F53AAD1971AAFDE658859975EE37CF96 and
439D954F18F79CC4F71BED91CACED996BC15C85A.
$ gpg2 -s -a --default-key testing
gpg: Warning: value 'testing' for --default-key should be a long keyid or a
fingerprint.
gpg: Error: the key specification 'testing' is ambiguous (passed to --default-key).
gpg: 'testing' matches at least: 362D3527F53AAD1971AAFDE658859975EE37CF96 and
439D954F18F79CC4F71BED91CACED996BC15C85A.

Whoops, I closed the wrong bug report, sorry. Reopening.

Comitted in a958ffd.

Comitted in a958ffd.

The patches are now rebased on top of f7505b550dd591e33d3a3fab9277c43c460f1bad.

In addition to these a modified rsa generator is needed to be FIPS 186-4 compliant.

We ended up using this patch from Fedora:
http://pkgs.fedoraproject.org/cgit/libgcrypt.git/tree/libgcrypt-1.6.3-rsa-fips-keygen.patch

Committed (ec409e6).

D253: 718_0011-Fix-testsuite-after-the-FIPS-adjustments.patch

D254: 717_0010-Add-new-pss-option-to-fipsdrv.patch

D255: 716_0009-Add-possibility-to-specify-salt-length-for-PSS-verif.patch

D256: 715_0008-fipsdrv-Add-support-for-RSA-keygen-tests.patch

D257: 714_0007-Fixes-for-RSA-testsuite-in-FIPS-mode.patch

D258: 713_0005-Use-2048-bit-RSA-keys-for-selftest.patch

D259: 712_0004-Disable-non-allowed-algorithms-in-FIPS-mode.patch

D260: 711_0003-PBKDF2-add-upper-bound-for-derived-key-length.patch

D261: 710_0002-ECDSA-adjustments-for-FIPS-186-4.patch

D262: 709_0001-DSA-adjustments-to-conform-with-FIPS-186-4.patch

Fix in cd2d685.

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]

Based on Werner's response, I believe that the underlying issue is resolved.
Thus, I'm going to close this.

Committed in de9b234.

Committed in e16d716.

Frankly, I do not like the hidden key feature in particular if used to
encrypt-to-self. The problem is that if someone encrypts to a group and forgets
to add your key, gpg will do a trial decrypt which is pretty annoying. Maybe we
can add a second kind of wildcard keyid to rfc4880bis which states that this has
been encrypted to the key of the sender

I have no idea what a trusted extension is and I can happily read / modify the
body through OOM.

I'm marking this as resolved as I don't see anything to do here.

We don't ship gtksecmementry any more so that is definitely no longer relevant.
Closing.

This is still the case.

GtkSecureEntry has been removed from pinentry.

The attached patch builds on the patch in #806. It provides a
--encrypt-to-default-key. One could imagine adding an
--hidden-encrypt-to-default-key as well. Werner: is this acceptable?

D44: 706_0001-gpg-Add-encrypt-to-default-key.patch

I implemented this as follows: it is possible to specify --default-key multiple
times. The last specified key for which a secret key is available is taken. If
multiple such keys are available, the others are simply ignored. The patch is a
bit noisy, because we need to pass the ctrl structure around. But, I've tested
it as follows:

  gpg2 -a -s --default-key 58859975EE37CF96 --default-key 58859975EE37CF95

and it correctly takes the 96 key, which is available (95 is not).

Werner: thoughts?

D43: 705_0001-gpg-Allow-multiple-default-key-options.-Take-the-las.patch

Fix in ea99f88.

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.

re T2120 (wk on Oct 19 2015, 07:54 PM / Roundup): of course I meant "Now".

Yes, thanks for the quick review and merge! I assume this will be released in
whatever release comes after 2.1.9.

I'm setting the status here to "resolved".

Thanks for the quick fix!

No available with 2.1.9.

I already applied your pacthes. May I close that bug?

With the informsec code we had "decent" support for encrypted / decrypted
attachments.

With 1.3.0 we have very nice read support for MIME Attachments (including
Outlook's internal preview). And send support is on the roadmap.

But this is event based code. I'd say we can close this issue.

I have to check if this is possible (Depending on the parameters in the forward
reply events this could even be trivial)

You may want to try out the latest 1.3.0 Beta version which supports reading
PGP/MIME mails. See:

https://wiki.gnupg.org/GpgOL/Development/Testversions

Fixed in the repo. Will show up with the next site rebuild. Thanks.