Backported for VSD 3.4

Done. Example (with default text in English and German translation):

[Welcome]
welcome-text[$i]=<h2>Hello, World!</h2>
welcome-text[$i][de]=<h2>Hallo, Welt!</h2>

TL;DR
This ticket was created because building static-linked gpgv shows warnings from glibc for getpwnam and getpwuid.
Basically, we can/should ignore the warnings from glibc at link time (for normal use cases), because it is irrelevant.

Current state in gpg4win-5.0.0:

Let us mark this as a feature requests. gepwnam(3) is a standard libc function and if glibc does not support it; this is more likely a glibc bug than a bug in an application.

We decided not to do this.

Option works in Gpg4win-5.0.1 with GnuPG 2.5.17

I think this is still open (and requires T6537: Make KIO::move work on Windows when moving between different partitions).

@werner I added an implementation https://dev.gnupg.org/D622
that matches Linux behavior and avoids the message about secure memory not being supported on Windows. The change is scoped to the pinentry tool and intentionally follows Linux behavior. Does this approach look reasonable to you?

I don't think that we will implement that any time soon. Today we too often require more mlock-able memory than available and in this case Libgcrypt resorts to allocating new memory arenas which are not locked. This is not as worse as one might think: the majro advantage with secmem is that a free() on secmem allocated memory will also wipe that memory. A better solution has always been to use an encrypted swap/paging file. 25 years ago, it was not easy to configure but today there should be no problem and hopefully already the default.

While key generation works now with an expiry date up to 2106-02-04, the representation on the command line is a bit ugly.

Current state needs to be tested

We need to test the current state

Backported for VSD 3.4

I think this is a very good idea. Go ahead an backport, I'll change the ticket description accordingly.

Fixed in: rC2c1d41b5f86f: fips,cipher: Fix the regression with disabled public-key algo.

Re-opened because a regression is reported.

I'll wait for feedback before I backport this.

Instead of adding yet another option I have optimized the case that a single archive containing a single top-level folder is decrypted/extracted (which, typically, is the result of encrypting a folder). In this case, the single top-level folder extracted from the archive is moved to the user-given output folder instead of the outer temporary folder the archive was extracted to. I think that's what most users anyway expect so that an option is superfluous. In case the extracted folder clashes with an existing folder in the user-given output folder then, as usual, the moved folder gets a numbered suffix to avoid the naming collision.

setting to High as we need this for T7790

Implemented and backported for VSD 3.4

The gpgme logs show that the information for revoked keys should be there. We just need to check for it (and somehow visualize it).

pub:o:3072:1:3DA05D6B0A5998AF:1768822823:1863514800::::::::
fpr:::::::::C70F6D8F32DFE96F5C47C40B3DA05D6B0A5998AF:
uid:o::::::::search (valid) <search@gnupg.test>\r:

gpgme.log (vsd 3.3.4):

Another possibility would be to just add a revoked column (expiration date is already shown) to keep closer to the ldap schema.

It works well for us. Thanks again.

The suffixes _ENCRYPT_SIGN and _ENCRYPT are used to differentiate the two export results.

or maybe for the fist one "_ENC_ONLY"

This has finally been merged.

implemented TypeScript workflows using tsc without vite

So w/o the new option we have:

The behaviour might have changed a bit because of the ldap: prefix i use now, or i have missed this case the last time:
Given some cert on the "download" server, I can find it, if dirmngr.conf contains only the "download" server, or if the "download" server is listed first:

Independent of keyserver order in dirmngr.conf, --search-keys still offers keys from the upload server, but the download fails:

For "Although the upload server is used for upload, the gpg message still displays the first keyserver" see T8025

in Gpg4win-5.0.0-beta479

I think we won't fix that for 2.2

Tested with gpg4win-5.0.0-beta479 @ win11

@tfry tested this, and it seems fine.

completed: draft all gpg key function names

I decided to prioritize developer experience and provide simplified, high-level functional abstractions instead of maintaining 1:1 parity with the underlying gpgme library functions. See example in T8021