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!

In T6161#162306, @ikloecker wrote:

I'm not sure I understand. If you don't want pinentries depending on libX11, then simply disable those pinentries with --disable-pinentry-qt5, etc. For Wayland it may make sense to allow disabling it.

I'm not sure I understand. If you don't want pinentries depending on libX11, then simply disable those pinentries with --disable-pinentry-qt5, etc. For Wayland it may make sense to allow disabling it.

Let's turn this into a feature request.

I pushed the change with documentation.

The PKCS#12 import was a late add-on because I consider P#12 to be a nasty and insecure format. Unfortunately it survived and is now the mainly used interchange format. Eventually we need to improve things here. However, ppl should use smartcards for S/MIME.

Thank you for your work on the proposal. I have two comments:

• Do we have some test vector, which can be used in the testsute to test the new API?
• We need to mention the new API in the documentation.

I tested with a self-signed one.

Did you test with a self-signed cert? I ran into the problem that the selection only showed the root certificate, the signing works using the leaf cert, but the root cert was put into the signature. Changing Scute to only return the leaf certificate made it work but verification failed.

I can successfully sign with LibreOffice Writer (using Brainpool with Yubikey). I need to do:

• Tools
  • Optoins
    • LibreOffice - Security - Certificate Path
      • Select the profile of "firefox:default-esr" for NSS certificate directory

Probably, PIPE_REJECT_REMOTE_CLIENTS mode and lpSecurityAttributes=NULL is OK.

Experimental branches:
https://dev.gnupg.org/source/libgcrypt/history/t4873/
https://dev.gnupg.org/source/ntbtls/history/t4873/

Any progress on this?

While playing with your scripts I figured that it would be useful to enhance the KEYINFO command. With
rG989eae648c8f3d2196517e8fc9cce247b21f9629 we could now

The option to flag a user ID as the primary user ID is now available in the Certificate Details dialog as button below the user ID table and as context menu entry of the user ID table.

Firefox nicely shows the 3 NIST certificates from my Telesec card but not the important Brainpool certificate for eIDAS. It turns out that Firefox does not support Brainpool, despite that a patch has been provided 8 years ago. See https://bugzilla.mozilla.org/show_bug.cgi?id=943639 . Thus there is currently no way to use LibreOffice or Okular to signe PDFs because they rely on NSS.

Agreed

I think this was mostly covered with T5362: Kleopatra: Add warning in compliance mode if gnupg version is not compliant and T5653: de-vs and GnuPG 2.3.3 error.

Has this been implemented?