Do you have any hint how I can test this? I installed Chinese-Simplified (zh_CN) but I fear switching the display Language. Maybe I should just use _wasctime and convert to utf8

This was actually implemented in a similar way for T3490.

Thanks for the report and the helpful suggestion. I was anyway about to change the time format but your suggestion is better.

I am not sure whether we need to fix things in kleo but at some places gpg uses atoi() to parse the seconds since epoch. This should be fixed because that is the way gpgme provides the expiry time. I will also look into the ISO date string parser.

Actually, a GUI to maintain the keys in an LDAP would be helpful for many sites.

This works insofar that it is now possible to set "none" (via the registry in VSD):

Tested on the command line with

• a previously valid certificate after setting its root certificate to untrusted
• a expired certificate without the root certificate in the certificate list

With VS-Desktop-3.2.0.0-beta214 and Gpg4win-4.2.1-beta31 the error is "Bad Passphrase" in this case.
I do not see a reason why this ticket is still open.
The already resolved Kleopatra Task T5713 is probably a duplicate of this one.

That should be easy on Unix but on Windows we have the nul nul: and iirc also /dev/nul.

In T6556#175399, @werner wrote:

@iklocker: Which gpg bug to you mean?

I don't see a value to do this for 2.2 and introduce a regression with that.

@iklocker: Which gpg bug to you mean?

BTW, with one of the recent gpgme fixes we now get

$~/b/gpgme/tests/run-keylist  --extern --verbose foo
run-keylist: file /home/wk/s/gpgme/tests/run-keylist.c line 414: <Dirmngr> No keyserver available

which is what users (and kleopatra) expects.

Note that for vsd we also need to change our default configuration file. The new "none" value provides a better error message than the old default of assuming that the AD carries the keyserver (which it does not in practise).

Thanks. For the record, done at https://lists.gnupg.org/pipermail/gnupg-users/2023-August/066692.html.

For reference this is the code used to fill the pubkey table:

static gpg_error_t
store_into_pubkey (enum kbxd_store_modes mode,
                   enum pubkey_types pktype, const unsigned char *ubid,
                   const void *blob, size_t bloblen)
{
  gpg_error_t err;
  const char *sqlstr;
  sqlite3_stmt *stmt = NULL;

You are right - issuing an SQL statement returns the rrror. Hwoever, the selfcheck from sqlitebrowser does not show any errors.

In T6679#174951, @werner wrote:

The copy of the database we received for this case is not damaged. A possible problem might be insufficient rights to read the database. For example created with an Admin account and then later used by a different user.

The copy of the database we received for this case is not damaged. A possible problem might be insufficient rights to read the database. For example created with an Admin account and then later used by a different user.

Not easy do decide whether something is a PIN or a PUK and we will need to check a lot of places. So, not now.

Turning this into a feature request: We should create P12 files using AES instead of 3DES

It may be better to open a separate issue for the issue in gpg, so that it's not overlooked/forgotten when the issue in gpgtar is fixed.