Please note that: libgcrypt offers ECDH functionality by gcry_pk_encrypt/gcry_pk_decrypt to construct OpenPGP public-key encryption/decryption.

So, this is only for OAEP but not for ECDH? FWIW, GnUPG uses OAEP only for S/MIME.

It's not that needed, in my opinion, as nobody actually uses ECB itself (in real use case). But I understand the point of (possibly, students') benchmarking.

Cool, I will try it out ASAP. You must have read my mind. Only yesterday evening I ran into problems because the current code in src/Makefile.am to symlink the static libs did not work on my new dev system with a lib64 layout and thought that I needed just a patch like this to fix it properly.

Pushed the change, although it is not enabled yet (since the feature will be only available by newer libgcrypt, 1.11).

Pushed.

Pushed to master.

By 1/N...5/N, it works. And it shows the API needs clarification and possible modification/fixes; As written in the comment of system-w32.c, fd == POSIX fd semantics is good, which asks API/ABI break.

In T5790#163980, @manonfgoo wrote:

@margirou:

Can you test the Patch, does it work for you ?

Kind regards,
Manon

In T5790#163886, @werner wrote:

[Merging didn't work]

Can you test the Patch, does it work for you ?

Here is the patch as file:

The patch applies with -p1 to the master brach, alternatively I could push a commit, but my user does not seam to be allowed to do so:

[Merging didn't work]

In T6229#163870, @werner wrote:

The other key slots are claimed to be used for expired or archived keys as you rightfully mention. We need to figure out the real world semantic behind this before we can repurpose such keys.

Pleaee have a look at https://dev.gnupg.org/T5790, i added a patch.

Attached you find a patch to this issue. This Patch sets the "keypair" attribute to the keys 0x82 to 0x95 unconditionaly.

The other key slots are claimed to be used for expired or archived keys as you rightfully mention. We need to figure out the real world semantic behind this before we can repurpose such keys.

Most PCKS#11 drivers are proprietary software which do not fit well into a free software system. Thus we avoid them. And of course we provide pcksc#11 support: Install Scute. There are no workarounds like alternative gpg-agent's - those things don't work reliable and are not supported.

Let's don't forget that we need to have a sig_class replacement.

Merged the changes in t6002 branch into master.

Applied and pushed the change from @joeyberkovitz in rG3257385378bb: dirmngr: Interrogate LDAP server when base DN specified..

BTW, I have also in mind to use an AD entry to figure out the used keyserver. It turned out that people don't like to modify the schema of their AD but instead use a separate LDS.

To proceed, I pushed an initial part as rG993820c31521: dirmngr: Factor out interrogate_ldap_dn function., which doesn't change any behavior.
Then, the point of the change will be clearer.

pinentry-emacs is obsolete. It's for older Emacs (<= 25, IIUC) which had lisp/pinentry.el.
For Emacs 26 and newer, you can simply use epa-pinentry-mode having the value of loopback.

Testing gpg-auth : There are two different use cases

• test with xsecurelock for screen lock
• test with pam-autoproto for login / gdm / etc.

Here are pam_authproto.c with Makefile, so that you can compile it with libpam:

What is a partial CRL; I have never seen that and IIRC the specification for that was not complete.

We want to get rid of sshcontrol but we could keep it as an optional configuration to sort keys. I won't say it is a bug, though.

For what it is worth, I think that my patch is more standard compliant then yours because it checks if there is a partial CRL.

I think 289fbc550d18a7f9b26c794a2409ba820811f6b3 implemented this wish from 2016 :) @werner please read the full report and then close it as fixed if you agree. I find it a bit funny that we both came independently to the same conclusion, that it should be handled differently even if the standard says otherwise. Because the behavior from the standard does not make sense and is in contradiction to other parts where it says that each CRL must contain all revocations.

just checking in about getting this patch reviewed

I hacked configure.ac of gnupg to force it build with libgpg-error 1.45, and OpenSSH works with the created pipe. Maybe the libgpg-error fix is only necessary in some certain circumstances?

Here is a PAM module, which interact a spawned process using authproto protocol of xsecurelock.

It's not yet pushed, because it requires new release of libgpg-error (for T6112: libgpg-error,w32: bidirectional Pipe support for estream).

I was looking for this when writing the update NEWS for the latest release and noticed that this has not been pushed yet. I really think that it would be nice to have that. Especially for Smartcard use cases.

We could use single letters or icons (with proper tool tip and accessible name). I'm not sure mentioning the cert usage is that useful.

Another point where this is very problematic are S/MIME certificates for signing and encryption. While the certificate line edit and the certificate combo box filter the usage, Groups are problematic. If you want to create an encryption group and include one "signing only" certificate the whole group is no longer visible for example in Outlook when encrypting. Both me and Eva thought that S/MIME Groups did not work at all in Outlook because of this.

Should be OK for mingw.org's MinGW. I cannot test the MinGW64 bits, but I trust that you did.

I encountered this issue of struct stat when compiling for x86_64 of Windows.
I'm considering this patch:

diff --git a/common/sysutils.c b/common/sysutils.c
index c30f9a0ce..bbed309a8 100644
--- a/common/sysutils.c
+++ b/common/sysutils.c
@@ -1237,10 +1237,20 @@ int
 gnupg_stat (const char *name, struct stat *statbuf)
 {
 # ifdef HAVE_W32_SYSTEM
+#  if __MINGW32_MAJOR_VERSION > 3
+    /* mingw.org's MinGW */
+#   define STRUCT_STAT _stat
+#  elif defined(_USE_32BIT_TIME_T)
+    /* MinGW64 for i686 */
+#   define STRUCT_STAT _stat32
+#  else
+    /* MinGW64 for x86_64 */
+#   define STRUCT_STAT _stat64i32
+#  endif
   if (any8bitchar (name))
     {
       wchar_t *wname;
-      struct _stat32 st32;
+      struct STRUCT_STAT st32;
       int ret;

TLS 1.3 requires much changes for NTBTLS.

Could this be reconsidered, as a way to support "allow-external-cache" in pinentry-qt? I am trying to use pinentry-kwallet, which saves the passphrase in kwallet, but there is no checkbox if the underlying pinentry is pinentry-qt.

I realized that some AEAD cipher (including GCM) allows arbitrary length for IV.
But it's not good for the API of setup_geniv and geniv.

That's a fair point, cheers!