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

Traditionally we have considered expired and revoked more or less similar. The idea is that an expired key might have been compromised but the owner did not found a way to revoke it. We may want to change this policy because some users don't care too much about expired keys (cf. T7990) .

I may have misinterpreted what The GnuPG UI Server Protocol is. Instead, I will provide high-level functions to all of gpgme's underlying features

Frankly, he OpenSSH support for Windows was experimental and I have never tested it. If it can be confirmed that this really works and is useful, it will be easy to add the opeion to gpgconf.

Regarding my comment T1825#191055 : The mane page has long been updated and gpgme support is also available. For the symmetric session key, see the feature request T8016

Looks good to me on gpg4win-5.0.0-beta479 @ win11:

• gpg --show-only-session-key --decrypt FILE shows only the session key
• gpg --add-recipients -r UID1 FILE adds recipients (tested with one or more uids)
• gpg --change-recipients -r UID FILE changes the recipients (tested with one or more uids)

Frankly, he OpenSSH support for Windows was experimental and I have never tested it. If it can be confirmed that this really works and is useful, it will be easy to add the opeion to gpgconf. Note that the gpgconf option feature handles only a subset of all options on purpose.

The problem was the keyserver configuration, which does not include a scheme (ldap:):

keyserver ldap.gnupg.test:389:uid=LordPrivySeal,ou=GnuPG Users,dc=gnupg,dc=test:pass:dc=gnupg,dc=test: