Hmm,

$ gpg --with-colons --list-config curve
cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;brainpoolP256r1;brainpoolP384r1;brainpoolP512r1;secp256k1

How would Kleopatra know that cv* is for encryption, ed* is for signing, and all other curves are for both uses? Or are the cv/ed prefixes a (de facto) standard?

You may run

For GnuPG 2.2, it's better to be conservative (least change of behavior, if any).

We have tests in gniibe/new-pk-api, which can be backported.

• t-dsa
• t-ecdsa
• t-rsa-pss
• t-rsa-15

Thank you, applied.

The patch has been applied.

Thank you, applied.

Thanks jukivili for the review.

I have just a note about this issue, that it would be helpful to exercise this new API in some tests. Right now, only the old API is tested.

It turns out that the asymmetric key operations are not yet properly enforced with the .disabled flag. While the other key crypto usually has some "open" api, where this can be simply captured, the pubkey API has several entry points and the "test_algo" is not enough to check for disabled key types.

Yeah, remove it.

Thank you. My local tests (in emulated fips mode and normal mode) do not show any errors with current master branch.

Hi guys, I just tested the git version (426d82fcf1c133bfc1d5c931109d71db3f3815a9) and it works well thank you.

Just to be correct: Kleopatra takes the default key algorithm from gpg's default_pubkey_algo pseudo option. (Technically, this pseudo option probably uses gpg's --default-new-key-algo option, but only if the latter is set.)

I get

Access Denied: Restricted Application

Ingo: Exactly we have the problem that we don't compile build tools before building for the target. So we take the build tooling like kconfig_compiler from the system we compile on. This means that we compile with the tooling from debian buster. Except for Qt which handles stuff like that directly and builds for example moc and the other tools correcly for the build system first.

And please let me know the change rC751fcadd34ed: random: Release memory in DRBG. affects t-secmem failure.

IIUC, one of the causes for the failure of secmem was resource release of DRBG memory.

Thank you for testing.

Applied. Thank you.

Fixed in 2.2.33.

An application should use syshd, instead.

@aheinecke: Please change the Original URL to https://dev.gnupg.org/w/gpg4win-or-gnupg-vs-desktop-bug-report/
. This creates a cover sheet which does not ask the user to login or register an account to later just realize that she may seatch the tracker w/o an account.

Thanks, however I didn't see your email on mailing-list. Maybe the email got stuck on the way.

Should be fixed. It's possible that the changes in KeyCache now cause unwanted recursion if some listener to keyListingDone() triggers a new key listing by some operation. This needs to be fixed for each listener separately.

@aheinecke Please provide an example of a PKCS#12 certificate.

Reassigning to Andre to check why the build system doesn't pick up kconfig_compiler from kconfig-5.77 which is used/built for gpg4win and the appimage.

Or are you trying to compile Kleopatra against KF5 that comes with Debian buster?

Hmm, cmake should find the right executable of kconfig_compiler. Are you sure that there is no development package of kconfig installed on the build system?

The is*Immutable members were added with version 5.68. And the current packages use KF5 5.77. So this should work. Unless ...

Thanks. I did some git archeology and found the first mention of this in the following commit in 2011 without much details:

Adding the case for == 0 only might be problematic, because I don't think it's an alias for a secure value; I think that == 0 means that it's up to libgcrypt to select the value (just like other generate_* functions).