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.

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.

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.

Can you do a search on the command line:

GpgOL konfigurieren - Version 2.5.3
Gpg4win 4.0.2
Windows 11
Outlook 365

Welche Gpg4win Version?
Welche Windows und Outlook Version?
Ist das die erste Installation oder ein Update?

I take this ticket. The way to go is removing all such cases.

Reference to a CVE for old MinGW-W64: https://nvd.nist.gov/vuln/detail/CVE-2018-1000101
https://sourceforge.net/p/mingw-w64/bugs/709/

At least old Windows versions did not add a nul in the truncation case. Thus I used to make that sure. I don't think we need it anymore.

Also applied to 1.10.

Applied and pushed.

AFAIK the above case has a lot of wiggle room to fit one PID and the surrounded string into 400 bytes and even if it would need to truncate, it would write terminating character, at least on Linux:

Pushed the solution which doesn't require new flag for libassuan.

^-- I withdraw the solution (with error value) above.

For me it is faster:

Or, it would be good for client side (in this case, gpg-agent) to specify the flag in the inquiry callback, that is, it's a kind of transient flag for a single transaction.

Revised version with new flag ASSUAN_CLEAR_INQUIRY_DATA.

Having written the code and the test I'm with dkg here. The code takes the expiration date, calculates the number of days from today and tells gpg to set the expiration to <number of days>d. The idea of the aforementioned is that it should work for any timezone. Maybe this assumption is wrong.

Subsequent downloads (also of the latest gnutls-3.7.5.tar.gz) where fast. Is there a configuration problem with loading uncached data, or was the bandwidth full at the first time?

Curious as to whether there's been any update on this. GPG4Win is the only approved whole email + attachment encryption solution on this end, and we're having trouble with inline images showing up as attachments only in Outlook 2016 (using GPG4Win 4.0.2). Of course, as you said, at least the attachment isn't being lost; however it does make reading rich emails more difficult.

Any progress on how the solution for this have been considered? Thanks.

I see the patch which does look like it will guarantee that the test suite succeeds. But does it solve the underlying problem, though? I worry that it might just paper over a more subtle problem.

Thanks. The solution should thus be easy.

It seems that editing a pre-created revocation certificate on Windows with Notepad doesn't let Kleopatra detect this correctly as OpenPGP file and thus refuses to import. Works on the command line but needs more testing.

For this particular issue of assuan_inquire, if it's needed, the point we should fix is:

AFAICS, we need to implement a new Assuan flag and wipe the data passed to the callback after the callback returned.

Glad to hear. I've also now had time to manually apply the patches and have not seen any issues so far! Thank you! If anything does turn up later down the road I'll let you know.

No, no apologize needed. You did your best for the bug report, and it helped us a lot to identify the issue, and it certainly helped resulting the fixes. Moreover, your report kicked another fix of T5979 (thanks to the valgrind output).
Thank you.

I apologize, you seem to be right. Even though the package build log shows that all patches were applied, it seems there are some hunks missing in the generated sources.
I've attached my patches, but those are most likely correct. There seems to be an issue with my distribution's package manager. I will investigate this and report back afterwards. Maybe I'll just build it manually.

I do not claim I understand anything of this assembler syntax :)

For the second, I wonder if newer xlclang++ compiler works with 1.9.

Thank you for the bug report.

Pushed the change.

When compiling the package, I can see that all 4 are applied.

I think that it means that you only applied the last two patches.

Thanks for your confirmation.

Thanks again for your update.

Okay, confirmed: I was just wrong and the build failure was only ever with --disable-asm (i.e. the log in this bug is the only relevant one). Patch works.

Please disable all other Add-Ins as well as extra security tools running on that machine to see whether there is some interference with them.

But only with an option - in general showing expired keys is annoying. For revoked keys the situation is different in case of a compromise - but many users revoke old keys anyway and we don't make use of the revocation reason. If we would consider the latter the UI/Support would be more complicated than useful.

Thanks a lot for your cooperation.

TL;DR: can reproduce, needs fixing

Maybe we shouldn't exclude expired or revoked keys from the list so that people can still choose them. Of course, those keys wouldn't be accepted to be used for encryption, but it would help people to find out why the keys are not acceptable.

My email to gnupg-devel@gnupg.org was accepted and is visible in the archives https://lists.gnupg.org/pipermail/gnupg-devel/2022-May/035063.html
Cool