Patch applied to master with small changes.

FWIW, on Unix is common to describe options as given on the standard shell.

The quotes are irrelevant because they are evaluated by the shell and don't make a difference here.

You need to install the correct Let's Encrypt CA certificates on your legacy Windows box. Check the mailing lists for a discussion on this topic.

No crash here

Duplicate of T6021. Please don't create a new bug for one you already created (and which was marked as won'tfix).

Added missing context lines and replaced some tabs with spaces

Fixed. Thanks for the report.

Yeah, seems to be related to daylight saving. Running

TZ='America/Adak' GPGME_DEBUG=3 TESTS="initial.test t-various" make -e check-TESTS

results in

FAIL!  : TestVarious::testSignKeyWithExpiration() Compared values are not the same
   Actual   (expirationDate)   : 2106/02/04
   Expected (QDate(2106, 2, 5)): 2106/02/05
   Loc: [/home/ingo/dev/g10/src/gpgme/lang/qt/tests/t-various.cpp(342)]

because the code adds 30555 days to the current time (2022-06-10-00:xx:xx+UTC-9) which gives us 2106-02-04-23:xx:xx+UTC-10.

I couldn't reproduce the one-off problem of the original report, but running the test with time zone UTC-11

TZ='Pacific/Pago_Pago' GPGME_DEBUG=3 TESTS="initial.test t-various" make -e check-TESTS

resulted in

FAIL!  : TestVarious::testSignKeyWithExpiration() Compared values are not the same
   Actual   (expirationDate)   : 2022/06/09
   Expected (QDate(2106, 2, 6)): 2106/02/06
   Loc: [/home/ingo/dev/g10/src/gpgme/lang/qt/tests/t-various.cpp(342)]

because adding 30557d (number of days in UTC-11 until 2106-02-06) to the current time resulted in a u32-overflow. I'll change the maximal expiration date to 2106-02-05 to avoid the overflow.

For clarification, the strings I have provided are raw argv elements as would be passed to execve(), with quoting already removed.

The quotes are irrelevant because they are evaluated by the shell and don't make a difference here. A Unix shell is different than Windows cmd.exe.

Please provide a more verbose report.

I am using GnuPG 2.3.4 on Fedora Linux. I am referring to --list-options=show-sig-subpackets="100"a (note the quotes). The bug is that the character after the trailing close quote is ignored, rather than being treated as an invalid option and causing an error. That is, I would expect show-sig-subpackets="100"a to be parsed as show-sig-subpackets="100",a or be an error.

gpg-agent --supervised being deprecated is highly surprising, especially because it works so well with systemd.

Please explain what you mean by this. Which GnuPG version, which OS, which shell, what is the problem.

The --supervised option of GnuPG is deprecated and thus it does not make sense to add this to keyboxd or even sdaemon (which is a helper to gpg-agent).

gpg tries to find the "best" key using get_best_pubkey_byname (https://dev.gnupg.org/source/gnupg/browse/master/g10/getkey.c$1507), but the applied rules are not clearly documented in one place.

Because it's the library which refuses null passphrase as input, only possible options are either:

Backported to GnuPG 2.2.

Added --enable-maintainer-mode to ./configure

Applied the changes.

Now, it also supports a reader with pinpad.

A use case for this is to allow the use of S/MIME for de-vs mode and for standard mode while clearly indicating compliant certificates. As of now all certificates matching compliant algorithms are indicated as compliant. The new flag could be used to distinguish between them.

The suffix .kgrp has been added as default filter for the import with revision rKLEOPATRA5c4d3a80d5a9: Allow the export of certificate groups.

Thanks.

Created gniibe/t5912 branch.
It works for me.

I can only find this one: https://github.com/patrickfav/singlestep-kdf/wiki/NIST-SP-800-56C-Rev1:-Non-Official-Test-Vectors