keep the macro as it is used

I don't have write permission to the repository.

I don't have write permission to the repository.

Now creation of OpenPGP certificates and CSRs from card keys in de-vs mode is only possible for RSA 3072, RSA 4096, and the Brainpool curves.

Back to WiP to also prevent usage of all non-brainpool curves (as requested by Werner in M9#117).

Thanks a lot.

Given that there is now also a restriction for rsa2048 in de-vs mode, can you please also restrict all non-brainpool curves?

Kleopatra doesn't have any restrictions when generating smart card keys. When generating OpenPGP certificates or CSRs off-card or from card keys, then in de-vs mode only RSA 3072, RSA 4096 or any supported curve (without any restrictions) can be chosen. Except for RSA 2048, Kleopatra doesn't know which algos are compliant or not compliant.

Backported the needed stuff:

Yeah, well, then the generation of ECC keys for smart cards is a 2.4 feature. I have implemented what you suggested: https://dev.gnupg.org/T4429#162056
If this suggestion doesn't work with 2.2, then it doesn't work with 2.2.

These are 2.4 features ...

What about --logger-fd? Does gpgtar pass all FDs through to gpg?

Okay, I'll skip those for now.

What does "SCD GETATTR KEY-ATTR-INFO" give you? What "CARDTYPE" and "CARDVERSION" does "SCD LEARN --force" give you?

This screenshot looks like you clicked on "Schüssel erneuern". Why is the title "ECC CSR gen from Yubikey"?

Commited this state with revision 1642162

no-tty and charset are anyway obsolete and passed only for older gpg versions. The other things should have useful defaults in gpg - in particular these defaults are taken from the same envvar as gpgme does. See send_pinentry_environment.

Not yet fully finished, but it's better for me to put it now:

This should really be in the next release.

Another thing I have noticed when turning qt debug output on is that the qt windows platformsupport fontdatabase logs over a a timespan of over two seconds that it is adding fonts to its database.

Some timings, timed with procmon and not by decorating the calls in the code. Just looking at was process does.

Currently the first call to QGpgMENewCryptoConfig::reloadConfiguration happens in the GpgSM self test. Funnily enough the selftest for gpg just returns true when the empty constructors of the cryptoconfig are called. The first component load is GpgSM.

Discussed with werner is for Wontfix as this is not really the AppImage way to do things. As you also seem to tend this way I slightly agree. I still would find it nice to have but If we have a real demand for that we can document or support people to do this.

Okay. It doesn't solve the problem that you want to run any application via the GnuPG VS-Desktop AppImage.

I am changing the priority here to high as the parent task has high prio. Maybe we should close this as a duplicate of T5478

I think AppImageLauncher solves this already. And for discoverability there's AppImageHub (which the distribution-specific desktop installers may already support as source for applications).

by moving the KUniqueService before this and with the change b58cf129f the priority is reduced. It will still take 200ms so we might want to do something about this but it is not prio high as the 200ms are only on first run.

Resigning as reviewer since I cannot close it, but want to have it off of my list.

Putting up for grabs and removing Kleopatra tag since for Kleopatra users this has been fixed (unless they manage to trigger multiple separate concurrent imports in Kleopatra).

Done for OpenPGP cards, PIV cards, and NetKey cards.

Hello Andre Heinecke,

I do not think that this is an issue after analyzing procmon timings. It is only an installation time issue. For that there is no real reason to spend much effort on this.