I also think this makes the most sense.

In my opinion, --locate-key should locate encryption key.

@gniibe oh, I see thanks for pointing out precisely main the problem. I will check the hardware supply chain RoHS 2002/95/EC

There are some problems with the definition of --locate-key. Further discussion required.

@pow, thanks for a reference. But problem here is that there are multiple products with same name.

@werner Yes, that sounds great, and would help already a lot, but extending it for card keys would be optimal. Thanks for your work.

Last week:

• Signed contract for the new office.
• Attended it-sa

In master (to be 2.3) you can add a Label: line into the sub key file of on-disk keys. I use this for quite some time now to show me alabel for my on-disk ssh keys so that I known which one was requested. We can and should extend this to card keys.

Last week:

• Problem of OpenPGP format definition
  • ECC object defined as "MPI"
    • it can be interpreted as "MPI" (big-endian), but actually not (composed by prefix, fixed-length big-endian x 2)
    • or it's not big-endian for EdDSA
• libgcrypt ECC (and GnuPG):
  • Binary object in SEXP handling
    • FIXED: public part should be handled by "/q" (or "/e") because it's actually not defined as big-endian

This week:

• GnuPG
  • Backport rG7535f1d47a35: gpg: The first key should be in candidates. to 2.2.
  • "/q" things
• libgcrypt
  • X448
• OpenPGP format
  • ECC clarification and X448

Same here, having YubiKeys and on-disk ssh keys from several computers, it is a bit a pain not to know which key is actually used. Any chances to get at least an update via manual editing of the comment?

I've also noticed this issue on windows when trying to symlink %APPDATA%\gnupg to $HOME/.gnupg under msys32.

Dear Martin,

Not sure what I did wrong this time, but it's broken again - GPG will again prompt for the PIN on my computer instead of on the Gemalto Ezio Shield reader :(

I'm using GnuPG 2.2.4-1ubuntu1.2 with your patch applied:

I believe that constraint of ret_keyblock != NULL is OK.
Pushing the fix.
Perhaps, backport to 2.2 should be done, too.

I have the same effect if I send a signed text-only or HTML email using Outlook 365 and our Exchange 365 and if I view the mail on Outlook on Android. The mail shows no contents only the file. If I view the mail using Outlook 365 on my PC or Windows 10 Mail it looks fine.
If I address it also to my Microsoft account and my Gmail account (using all adresses in the TO: field of the same mail) the email looks normal in the Gmail Android app and (!) in Outlook for Android.
So the same mail - both in the same Outlook for Android app - looks correct in my Microsoft account inbox but only shows the file in my Exchange inbox - in the same Outlook App. Weird… Nokia 7 plus, Android 9, newest patch level (September 2019) and no updates in Google Play Store.
BTW: In Exchange 365 I configured the message flow, default remote domain (there is no other) to never to use Rich Text, always and only HTML.

Thanks for the feedback! Right now it hangs only for a few seconds, then works as usual. No idea how this come, but I'll close the issue and contact the ML if it appears again.

(I ordered 4 of the RISC boards you mentioned)

Last week:

• Went through a large backlog of open mails / issue reports.
• Fixed handling of S/MIME mails that were moved in Outlook. So that they have the original message class again and the mime structure is not broken. The actual code was pretty small for it but it required some trickery.

In T4475#124816, @werner wrote:

Put

log-file /somewhere/scd.log
debug ipc,cardio
verbose

into ~/.gnupg/scdaemon.conf and kill scdaemon. Then look at the output. I would suggest to first stop the pcscd so that GnuPG's internal CCID driver will be used. Make also sure that there is no a permission problem with the usb port. In case of a CCID (card reader protocol) problem a

debug-ccid-driver

in scdaemon.conf will also be helpful.

Last week:

• Fix T4712: Keygrip broken in master for cv25519
• Chasing a USB bug in Chopstx (fixing this week)
• Reconsidering X448 change, more X448 friendly way (native one) is better

This week:

• Fixing T4713: Bug in get_best_pubkey_byname
• X448 native way in libgcrypt
• Start RISC-V support in Chopstx
  • Pre-Order: https://www.seeedstudio.com/Sipeed-Longan-Nano-RISC-V-GD32VF103CBT6-Development-Board-p-4205.html

Last week:

• Some work on keyboxd
• Patches to mitigate possible SHA-1 collisions
• General bug fixing work

I won't be able to attend

If we can assume ret_keyblock != NULL (it is, in current implementation), it can be as simple as:

diff --git a/g10/getkey.c b/g10/getkey.c
index 6802026f6..27bbd354c 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1354,6 +1354,8 @@ get_best_pubkey_byname (ctrl_t ctrl, enum get_pubkey_modes mode,
   int is_mbox = is_valid_mailbox (name);
   int wkd_tried = 0;

Please try with the latest GnuPG version (2.2.17) - it is unlikely that we can give support for an old version with Ubuntu's own set of patches. It is also advisable to post to the gnupg-users ML because over there you have hundreds of Ubuntu users.