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.

I guess we should follow the GNU standards and provide only info files ;-)

Firstly, I clean up the code with each individual thread for monitoring something; That's T6692 and T6693.
Then, I pushed rG76a2f180286e: agent: Better interaction between main loop and cache expiration. and rG92de0387f04b: agent: Introduce management of timer to expire cache entries.
No more use of tick, but timers.

Other problems of yat2m transformation:
https://bugs.debian.org/1050886

Nothing to test (except that the tool tips are now shown for the widgets).

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.

It's pushed by rG716e59b0b628: agent: Add agent_kick_the_loop function.

Pushed the change by rG7025375e8bec: agent: Have a thread monitoring parent PID and homedir.
It depends on T6682 to wake up the loop.

Push the code by rG95186ae92f92: agent: Use a thread to monitor socket takeover.

Thank you for the response, @werner! (original reporter here)

BTW. you should use gpg --quick-set-expire FINGERPRINT 5y this is easier for scripting. Using
--export-options no-export-clean should keep the old signatures.

gpg only uses the latest self-signatures and ignores old one. Thus I do not understand your problem.

thank you, i send you test mail
Regards

Hi, my suspicion with the different tenant is that some middleware of yours is inserting something like "DANGER this could not be Virus Scanned by your super secure and expensive middleware" which then results in the mail beeing multipart/mixed instead of pgp/encrypted in the MIME type. Could you ask your communication partner with the problem to send such a mail to you and with CC to "andre.heinecke@demo.gnupg.com

I was trying to solve it with support, but it was not solved until today, this issue we are facing more thank like 2years.
I guess its need to be solved with more advanced support than classic one.
Regards

Looks more like a support question but feel free to create a sample message, encrypt it to info at gnupg.com (WKD) and attach that message to this report.

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