When I replied to the bug report I had the very same idea. Thanks for adding.

Here is a test signature with long notation data. During verification gpg faults when emitting the NOTATION_DATA lines.

As Werner wrote, this is already possible. The next time please consult the extensive documentation of gpgme before opening a ticket.

Thank you. Applied.

ntbtls support only 1.2. We can't disable cipher suites for interop reasons. It is not the client's job trying to force a server 's admin to offer only decent ciphersuites.

Hmm, why not use:

gpgme_op_sign (ctx, in, out GPGME_SIG_MODE_CLEAR)

The buttons in the main toolbar can now be selected with Tab and Shift+Tab.

The original description of the problem seems to be wrong. gpg-agent does not have a KEYPARAM command. If I understand correctly then gpg-agent sends a KEYPARAM inquiry to the client, but you are sending KEYPARAM to the server.

I realized that we need to invent a way to represent KEYGRIP (40-byte string) in the scheme of PKCS#11; PKCS#11 uses fixed-size string (space padded) for it's label (32) and serialno (16). Basically, it identifies the device by slot number.

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.