Meanwhile all executables are signed.

Investigating GNU ld, I learned that there is no easy way (~= no way) to suppress the warnings (other than 2>/dev/null). It was implemented by the special section named gnu.warning.SYM where SYM is a symbol. I think that this is not-so-good for glibc to notify its users about possible static link problem, by gnu.warning.SYM.

Sorry for the ambiguity. The request was only about mentioning (bpX) for the first two choices, not to add more combinations.

Physical experiment feature support should better not be widely used.

Although it is technicall possible to use all combinations, we should limit in the menu them to those as listed above. Too many algorithms pose an interop problem. Thus we provide brainpool because it is required in Germany and the two IETF curves for the general internet (for those who are playing mitigation against against physical experiments).

Note: In vsd it must be restricted to the bp algorithms then

The blue Kleopatra icon is now used for the Windows builds of Gpg4win and GPD and for the corresponding AppImages.

Thanks. Will go int the next version.

Done and backported for VSD 3.4

I misunderstood this, the mail can be forwarded with attachment if you first deselect the mail and then select it again. So the workaround is OK.

We decided to still use the term "Valid" (with description/tooltip "Certificates that are neither expired nor revoked (except disabled ones)"). This matches the use of the term "invalid" for expired and revoked certificates as in "Certificates that are invalid because they have expired (except disabled ones)".

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"