Thank you for reporting, and sorry for late handling of this report.

Push the change.

Thank you for your report. Next time, please include information of your target and configuration in the report.

To identify/locate the issue, you can try command line:

In the situation of a certificate about to be expired in the cache:

TLS 1.3 requires much changes for NTBTLS.

Applied to master and 1.10 branch.

T6142 was solved by rejecting expired root certificate.

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.

rejecting an intermediate certificate too.

Pushed the change of mine to master, since I can confirm that it results validate_cert_chain working better, because of put_cert's rejecting an intermediate certificate too.

I pushed the change with documentation.

I pushed the changes. It also cares about the case for --cflags.

@orbea Thank you for your suggestions.

Thank you @dkg for the analysis. Unfortunately, the certificate cache is hashed by SHA-1 FPR, so, I think that it is a bit difficult to implement moving certs "front" / "back".

I think that for GnuPG 2.3.7 or later, you can add "Prompt: no" in your private key, which helps your interactions.
https://dev.gnupg.org/source/gnupg/browse/master/agent/keyformat.txt$138?as=source&blame=off

Fixed in 1.2.1.

Fixed in 1.2.1.

Fixed in 1.2.1.

I wrote a simple testusb.c if monitoring USB devices works:

#include <stdlib.h>
#include <libusb.h>
#include <poll.h>
#include <stdio.h>

What I learned today:

• libusb backend for Linux does:
  • scanning devices, it uses hotplug feature
  • hotplug feature uses udev_monitor_new_from_netlink and udev_monitor_receive_device, which are available in libudev (it communicates udev through AF_NETLINK socket)
  • libudev differs in Devuan
    • Distributions with systemd, libudev nowadays includes static-libsystemd
    • In Devuan, it is included in eudev : https://git.devuan.org/devuan/eudev
  • At initialization, hotplug feature spawns linux_udev_event_thread_main (its name is {libusb_event})
    • It is this thread, which receives information of device insertion/removal

Original pkg-config supports PKG_CONFIG_SYSTEM_LIBRARY_PATH (default is determined by build time, and overridden by environment var), PKG_CONFIG_SYSTEM_INCLUDE_PATH as well.

In libusb (1.0.26), I found this:

diff --git a/libusb/os/linux_udev.c b/libusb/os/linux_udev.c
index 9ec9eb17..66e27244 100644
--- a/libusb/os/linux_udev.c
+++ b/libusb/os/linux_udev.c
@@ -194,9 +194,11 @@ static void *linux_udev_event_thread_main(void *arg)
 		}
 		if (fds[1].revents) {
 			usbi_mutex_static_lock(&linux_hotplug_lock);
-			udev_dev = udev_monitor_receive_device(udev_monitor);
-			if (udev_dev)
-				udev_hotplug_event(udev_dev);
+			do {
+				udev_dev = udev_monitor_receive_device(udev_monitor);
+				if (udev_dev)
+					udev_hotplug_event(udev_dev);
+			} while (udev_dev);
 			usbi_mutex_static_unlock(&linux_hotplug_lock);
 		}
 	}

I tested with a self-signed one.

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

gpg-error-config and its relatives (libassuan-config, included) were written before pkg-config. The support of cross build, multiarch, and multilib by those are quite limited (and sometimes wrong). Basically, those scripts are deprecated, but it has been kept for backward compatibility.

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

Thank you for your log.

@ikloecker Thank you. You're right. Please go ahead.

Note that gpgrt-config supports the PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR environment variables.

It's in 1.18.0.

It's in 1.18.0.

Please note that with newer libgpg-error releases, you can safely not install or can safely remove installed gpg-error-config. For GnuPG and its friends (including gpgme), gpgrt-config with gpg-error.pc are used instead (when no gpg-error-config).

Push the change.

gpg-error-config (which is old shell script to offer functionality of pkg-config) gives -L/usr/lib64 when it is configured at the build time.
gpg-error-config hasn't got improved, but kept its behavior (for backward compatibility and lesser surprise), while we are moving to the support of gpg-error.pc (by pkg-config and/or gpgrt-config).

Indeed, you are right. The object created by with can be valid even after the context (when referenced by another object).

I think the fix should be something like this:

diff --git a/lang/python/src/core.py b/lang/python/src/core.py
index 81f961d9..95fd0cba 100644
--- a/lang/python/src/core.py
+++ b/lang/python/src/core.py
@@ -1189,8 +1189,9 @@ class Context(GpgmeWrapper):
     def __enter__(self):
         return self

@jap Thank you.

The SEGV was due to access to gpgme library after self.wrapped is set to None in the __del__ function.

The commit is: rMb2f224a471fe: python: Reset passphrase callback correctly..

Thank you for the patch. You are right.

For the firmware 5.4.3, I confirmed that it works well with the changes:
https://dev.gnupg.org/T6070#160150

Probably, PIPE_REJECT_REMOTE_CLIENTS mode and lpSecurityAttributes=NULL is OK.

Here is the parser output:

$ python3 sd.py --type=pipe "D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU)"
D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU)
    Discretionary ACL: P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU)
        Flags: P: SE_DACL_PROTECTED (Blocks inheritance of parent's ACEs)

I think that the last argument of CreateNamedPipeA can limit the access to the named pipe.

Here is a patch to implement the functionality with --enable-win32-openssh-support.

Fixed in master.