Eva tested a few expiration dates for new keys: For 2038-01-18 the date is correct. For 2038-01-20 and 2106-02-05 the expiration date of the new key is 2038-01-21 and 2106-02-06 respectively. Kleopatra passes the date as ISO date.

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: my brainpool X509 testcertificate is shown as compliant

In VS-Desktop-3.1.90.258-Beta it is "no space left on device" now in the encrypt/verify window.

A quick test shows that the latest patches allow to set and show an expiration date beyond 2038. A new VSD beta will soon be available to customers. And we should also think about getting a gpg4win bug fix release out.

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.

This works now. Tested both decrypt and encrypt. Sadly just one commit after GPGME 1.23.0 but this was a miscommunication because I was a bit unavailable :( But we can patch this into our installer.

While trying to replicate your findings I might have found a but in the import code which rejected one of the keys (using gnupg 2.2). I'll take care of this.

T6536 has been fixed. With today's commits the Brainpool curves are now also flagged as compliant in gpgsm.

and it is also confusing that you can choose the key for signing in Kleopatra, it is displayed with a green check mark but then you run into an error:

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.

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.

works now with VS-Desktop-3.1.90.246-Beta

The error message in Kleo is now (with VS-Desktop-3.1.90.246-Beta) "Broken pipe". But in the linked error protocol you can find the gpg error message "no space left on device". So I would find this message acceptable.

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):

works!

I forgot to backport one patch. With that patch we get what we expect:

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

That has been done modulo the bug which existed for both versions, I fixed today (T6536)

@ebo: Du have the Ted Tester key (i.e. the ADSK key) also in you keyring?

According to werner the gnupg tools use GetCommandLineW even when they are not build with -municode.
So a solution could be to build gpgme-w32-spawn with -municode and start the child process with CreateProcessW, this would also solve the problem that GnuPG could itself be installed into Paths which are not representable in the local 8 bit encoding.

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.

Works, setting "compatibility-flags vsd-allow-ocb" in the gpg.conf causes new keys to be generated with the AEAD feature flag OCB. And encryption to that key then uses OCB mode as long as the compatibility-flags is set.

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

In 2.2, KEYINFO output doesn't support A-flag for the information if card is online or not.
We need to clean up this discrepancy.

I pushed rGff42ed0d69bb: gpg: Enhance agent_probe_secret_key to return bigger value. to fix this issue.

I think there is a timing issue between the termination of a job and the retrieval of gpg's output, so that gpg's output is sometimes truncated or even completely empty. This is a general problem and not specific for this ticket.

Encryption to the ADSK seems to work but I'm not sure if everything is displayed as expected.

works with VS-Desktop-3.2.0.0-beta214, too.
You are now informed that you do not have permissions to write there.

For VS-Desktop-3.2.0.0-beta214 this does not work yet. If a keystub exists, it is not overwritten.

Kleopatra now shows:

works in 22, too (tested with VS-Desktop-3.2.0.0-beta214)

Does not work yet on VS-Desktop-3.2.0.0-beta214:

Tested in VS-Desktop-3.2.0.0-beta214 by encrypting a large file with Kleopatra. The progress bar shows percentage finished, progress looks all right

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

pkcs12 import should be backported, too

works

Was already with gpgme 1.21.0. Note that I used the done column but in future a milestone would be more useful than that catch all "done".

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?

@iklocker: Which gpg bug to you mean?

Bugs goes back to 2002 where we stopped checking trust for keys without any signature. This was really useful but has this strange behaviour.

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).

Thank you.

Backported to 2.2 branch.

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

I am not sure about the initial state of the key. What you are doing is to sign the key with itself (self-signature). Why?
In any case, I can't replicate this. Let's talk about this next week.

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.