hmm, almost. With VS-Desktop-3.1.90.258-Beta I do not get an error any more, a key is generated. But the "vaild until" date is off by one day, it is one day later as the one given at key generation.

works, the secret part is now imported, too, tested with VS-Desktop-3.1.90.258-Beta

For the VSD branch it works, VS-Desktop-3.1.90.258-Beta

Thanks. I'll apply your patch.

For 32 bit WIndows I now hacked some extra code to handle the expiration time if given as ISO string. Although gpg won't display the time correctly on the command line, Kleopatra does this and also allows to set the expiration time.

Or better wait. We can now pass "seconds=2147483648" as expire value but that is added to the creation date which might not want we want. I'll look again into this.

Would love to test this, but I can't seem to compile this project, getting stuck at The system does not provide a working iconv function. Is there a Fedora based dockerfile or equivalent where I could build it? Here is the reference Fedora source. I have tried to hack it and build from a gitarchive, but I am still encountering issues No rule to make target 'audit-events.h', needed by 'all'. Stop.

Now fixed in 2.2 and 2.4 (commits rG08f0b9ea2e955209d467f1ff624bf7abd10ae7ac and rG7661d2fbc6eb533016df63a86ec3e35bf00cfb1f). See also T6752

According to Werner this should work.

Well, this bug is fixed by using a decent libgpg-error or configure it correctly.

With VS-Desktop-3.1.90.246-Beta I can not import the secret part of the edward.tester@demo.gnupg.com.p12 Testkey (ECC brainpool).
I do not see any error message.

Thanks, what should I look out for? I don't think I can provide the .p12 directly because it is from a production provider that I do not have full access. I can provide the log and x509 public certificate again using the firefox generated one.

Needed changes in Kleopatra are tracked in T6761.

I am pretty sure that we have done everything in gnupg. Now if we only had a workboard for kleopatra.

Recent Mozilla again changed some things. Please see T6752. Can you please provide a sample in case this is not the same problem as in T6752?

Some time ago, I have checked and hopefully fixed all usage of time_t in Kleopatra and GpgME to make sure we always use unsigned 32-bit integer arithmetic. Dates entered by the users are capped to some date in 2106 (a few days before the overflow date).

Well I have looked at this ticket and posted a comment. We should talk about if there is anything left to do or not. I suspect that the gpg side is done and I should open one (or probably better several) ticket(s) for the kleopatra side.

And yes in gpgsm.conf both the extensions are also marked with ignore-cert-extension.

While remembering this I added to our standard.conf (and for testing first to my local conf):

115.3.1esr

Yes, there is clearly a problem with the handling of NDEF. I have a fix for that but there are other oddities in that pkcs12 object. Do you have the Firefox version you used to create this?

Applied to 2.4, too.

Form the Gnupg-2.2 commit rG936954a18a2df made sure that the hkps:// prefixing from kleopatra is ignored.

OK. I pushed: rG227b3b14f4be: tests:tpm2dtests: Modify tests with SWTPM and relax the condition.
... which doesn't require swtpm_ioctl and tssstartup any more.

I pushed rG321f9c0a3f28: tests:tpm2dtests: Fix tests with TPM2D. and rG98dd6f7af6aa: tests:tpm2dtests: Fix tests with SWTPM. (and other small changes).
Now, it works with two cases:

• tpm_server
• swtpm, swtpm_ioctl, and tssstartup

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