This is a support requests. Please consult one of the mailing lists or the gpg4win forum. In case this turned out to actually be a bug, please feel free to reopen it.

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.

Nevermind we clarified in chat that we would instead deprecate this API.

Kleopatra doesn't rely on the defaults in the library and other users shouldn't either. I would kill defaultkeygenerationjob. And it's use in newkeyapprovaldialog should be fixed, e.g. by using QuickJob::startCreate().

Btw. TBH I actually should read again about "explicit" in C++ I never really understood its necessity. :)

Thanks for the pointers. I just wanted to paste this as a differential so that it does not get lost in a stash somewhere on my system. I actually do not like this approach anymore. And do not want to commit it in this way. I would rather subclass or extend KAboutData with a verification option and then read from a QSettings style file instead of this Line based thing. For this I really think that an out of process call makes sense because the call is not to gpg but only to gpgv where we can just rely on the return code and even if we just patch it in having a GPGME dependency in KCoreAddons would be bad design IMO.

Why don't you create an MR on invent?

This adds a lot of complexity to a program which should be simple. I tend to say, just accept a small(?) race condition in cache flushing. The power issue of waking up every minute or so is a constructed one and does not result in a noticeable battery drain in real life.

I have a bad patch for this. D567 But I think we need a better solution that works without libkleo and could live in KCoreAddons as a change to KAboutData so that we can reuse it better for T6594

Changed the task description to easier find it

I concluded that it's just simpler not to do so. Since expected use cases are only for passphrase cache expiration and some monitoring something, it would be overkill.

Hi,
This is a classical support question. Please use one of the community channels under:
https://www.gpg4win.de/community.html
for this.

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

If we ever add a way to take the password from a file we will for sure hide that in the log files. Ceterum autem censeo tesserae esse delendam.

This is now done :)

This is now merged in master :)