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.

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

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.

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.

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.

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.

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.

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.

It turned out that we need to fix this for use by Kleopatra on Windows.

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

Needs to be checked for 2.4 - no backport to 2.2, though.

Needs to be checked again with stable. No backport to 2..2, though.

Won't be backported to 2.2 once we got something in 2.4.

We should not backport this to 2.2; better update to the current stable version (2.4)

[For bug reports please don't refer to some other site - at least a brief but useful description should always be included]

Sorry, I only now noticed that you used the --export-secret-ssh-key. Unfortunately commit
rGafe5fcda52e88438c7a7278117b2e03f510a9c1c states in the comment:
"Due to time constraints the code is not yet ready." Let's turn this into a feature request.

I mostly used ed25519 keys and thus I do the avove command pretty often without problems. Can you please add

-v --debug lookup

to the command line show us the log (send privately to my standard mail address (wk@gnu...) if you feel that data is too sensitive for the public).

We have no dedicated error to tell that the verification failed due to an non-compliant algorithm. Thus we return invalid public key algorithms as best approximation. You could use --override-compliance-check, though. We discussed things thing once at the Gutenbergweg.

The data is indeed corrupt. Check with the sender of that key.
IF you look at the data you will soon notice that one line is longer than the others.

Please ask on the gnupg mailing list for support. In case that turns out to be a real bug, please re-open this bug.

Here is an example from my QES cert:

That does not mean that this is a good idea. And well, I heard that Poppler does not have a stable API.

Don't do that. The key usage extensions rarely useful. This is the usual X.509 DbC (design by commitee) mess. See for example https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt . Let's not try to follow this path.

Good idea.

Use the is_qualified flag to figure out QES certificates. This is more than just a capability flag.

NonRepudiation is not a well defined term. It is used by X.509 but often used similar to a digital signature. Thus this does not make sense. The is_qualified flag is what we need for QeS and it seems we already got this in gpgme.