works: my brainpool X509 testcertificate is shown as compliant

Please excuse my question but this issue has been WIP for 8 months. I think it was forgotten a bit. Especially since we are not shipping Okular for general signing of PDF documents this issue might help as a stopgap for Smartcards which we do not yet support natively and reduce the pressure a bit to add more PKCS#15 smartcards which can currently be used with Adobe and Mozilla NSS through their proprietary PKCS#11 modules. So I would like to raise the priority for this a bit. But I don't think high is appropriate. That would be for werner to decide.

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.

Will be in 2.4.4. GPGME 1.23.0 with support has been released.

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

Well, see my very first comment.

yes, fixed

I think this was fixed with the fix for https://dev.gnupg.org/T6534

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.

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

C++ bindings also done.

Core part done.

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)

This was actually implemented in a similar way for T3490.

Aha, so you know how to provoke us into action, good man ;-) Alright I give it high priority. No seriously, makes sense to have we'll see when we can fit it in. Needs an extension in our internal api so probably not in the next release but sooner rather then later.

I guess I asked for it, because much older "PGP Desktop" had it already (via menu entry):

Mmh or even select all expired keys and then refresh them.

Multi select makes this nontrivial. But I think only with multi select this would really be useful. But yes it is a nice item for the backlog. E.g. if you know that a company switched their mail domain you might want to refresh all the keys from that company and you could do that with filter + multi select and refresh.

works

It's been a few years since this task has been active.

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

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

For Windows things are actually more complicate. It seems to be common practise of sysadmins to provide PAC files which are used to map URLs to proxys and to decide whether a proxy is to be used at all. Fortunately Windows provides an API to find the proxy for a specific URL. We should use this.

pkcs12 import should be backported, too

This sounds a bit more like you would maybe better suited with a batch script or command line usage anyway if you always want to encrypt in the same way you don't really need a fancy GUI for that.

PR that removes the "Show key details" link from the response email: https://invent.kde.org/pim/kdepim-addons/-/merge_requests/37

It took a bit of time to set things up, but I was able to manually perform the WKS dance and open each email in KMail to check how it 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".

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

It might actually be useful to have an random number API in gpgme. When we do that we can also add a way t search for random numbers with an upper limit in each octet.

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

What I would like to be able to do would be:

Why do you need an integer - for real random this must be larger than 64 bits and then you have problems to to find a suitable type for a variable.

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

The MSI Package though is a 64 bit MSI Package. For 32 Bit Windows we would need to ship a different MSI Package. (Which we actually have build support for because I thought that was neccessary even in 2020)

No, everything in Gpg4win is 32 bit, except for gpgol, gpgex and gpgme, libgpg-error and libassuan. Which are addionally installed under bin_64. But for the whole KDE stack it should easily be switchable. The KDE Windows project regularly builds them as 64bit applications. Basically we would then need to invert the logic and use the 64 bit compiler as the main compiler and the 32 bit compiler as the _ex compiler for gpgol and gpgme.

Kleopatra is a 64 bit application, right? For GnuPG we are working on 64 bit support for Windows. This is planned for 2.6. problems are how to represent sockets, file descriptors, streams and so on. Regarding the time interface, we should have everything ready in the GPGME<->GnuPG interface. In GPGME we need to check that we don't use int instead of time_t, though. When that has been done/fixed we could use a 64 bit gpgme and kleopatra along with the 32 but gnupg. Might be easier for approval reasons.

Mh, since there are no 32bit Versions of Windows sold for quite some years now maybe we should consider just going full 64bit with everything to solve this? Or is this a stupid suggestion?