https://twitter.com/charleslewisni4/status/1051021429637025792?s=20

https://twitter.com/charleslewisni4/status/1051021429637025792?s=20

https://twitter.com/charleslewisni4/status/1051021429637025792?s=20

Sorry, won't be able to attend today,

Last week:

• Struggled for T4713: Bug in get_best_pubkey_byname
  • Original problem of mine (newer key is not selected because the first one is not in the list of candidates) has been solved.
  • Should -r someone -e and --locate-keys someone match?
• libgcrypt ECC code clean up

On July, 19th, @werner wrote:

You need to wait a bit more.

Still unresolved...

Or... it could be a feature, not bug, so that failure of -e -r someone can be examined by --locate-keys someone.

Let me clarify the point.

GnuPG ships a non-PKI certificate, specifically to authenticate hkps.pool.sks-keyservers.net. Now due to an implementation detail, this has been shown to potentially lead to authentication of other domains by this certificate, if a maintainer changes the default keyserver via the DIRMNGR_DEFAULT_KEYSERVER variable in configure.ac. Now arguably, this variable isn't exposed via ./configure, so it's not "officially" configurable - but evidently maintainers do want to change it. A trivial one-line patch was supplied to change the unintended and potentially security-problematic behavior into the (I believe) obviously intended one.

I think that we should apply further change:

diff --git a/g10/getkey.c b/g10/getkey.c
index 077209415..1c337149c 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1369,7 +1369,7 @@ get_best_pubkey_byname (ctrl_t ctrl, enum get_pubkey_modes mode,
     *retctx = NULL;

I found more wrong cases of get_best_pubkey_byname.
For ranking results,
(1) It may return non-encryption primary key as the most relevant key, when its validity is higher.
(2) It may not select encryption primary key even if its creation time is newer.

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.