Sorry, I should have been more precise in my description of the problem. Specifically with --quick-addkey, gpg's behavior seems to be that the expiration, when given using seconds=... is treated as seconds from now.

FWIW, when updating the expiration time gpg does this:

My explanation of gpgme's behavior was not quite correct: Specifically in the QGpgMEQuickJobs for creating (sub)keys, the API uses QDateTimes, which are then converted to seconds since epoch.

That's both not correct. gpg takes the expiration time in seconds since creation time. For a new key this is close to the corrent time but not really. For an prolonging an expiration, this is of course different - the creation time of the key needs to be taken in account. I recall that we once had a discussion and agreed to keep it at time after the creation of the key. This avoids problems with the expiration going negative.

We could also use this for T6874: Kleopatra subkey management improvements

I think this works as intended now with the new certify interface. Also if you grant a key full ownertrust as now is the only option the self certification automatically becomes valid so this then shows as certified.

Just my five cents:

This is a generic parent task and does not require workboards for specific branches.

So as a replacement for what we have in Kleopatra this would work.

So with my ryzen 9 on tumbleweed:

For a very long time i would have agreed with you. But i now understand the usecase. You misunderstand that feature just like i had. It is not about checksum verification or checking. It is for detecting changes in folder trees so that you know when to reencrypt and update your encrypted archive of that tree. Yes this could be done somewhere else but the usecase is valid for kleopatra.

I would rather like to see the checksum stuff be ripped out of Kleopatra into a simple standalone app. It's complete overkill to start the Kleopatra battleship if the user just wants to calculate or verify a checksum of a downloaded file. The UI of the checksum tool in Kleopatra is anyway still not accessible (T6099: Kleopatra: Make checksum verification accessible). How about we redesign the UI from scratch with accessibility in mind from the start?

The tobias/gpgsum branch in gnupg now contains my implementation of this. Together with the attached patches to kleopatra and libkleo, it can properly handle unicode filenames on windows. I'll put those patches up for review at KDE in the next days.

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.