The proposed new expiration date is now the same as for the generation of new certificates, i.e. today + configured default validity.

I hate this ping-pong, but, as I wrote in my previous comment, for me canceling decryption does work on Windows, i.e. the gpgtar process does not keep running for a long time. That the gpg process keeps running is nothing Kleopatra can do anything about.

I have tested this with a self-built installer from a few minutes ago in my Windows VM. Whenever I canceled decryption (I tried it about 5 times), then the gpgtar process went away very quickly. The gpg process keeps running, but that's a bug in gpgtar: T6558: gpgtar: Does not stop spawned gpg process when exiting.

cancelling decryption does not work yet on windows

Should be fixed.

I don't think this is the right choice: Un Unix we have file descriptors which ar an (int) and on Windows we use (HANDLE) which is a 32 bit integer. See my comment in T6551 regarding values for HANDLE.

Just to clarify this change for readers not accustomed to Windows internals: This function was used to translate the file descriptor as passed to gpg (which is a HANDLE) to the libc file descriptor as used by stdio. Obviously we won't anymore work with stdio file descriptors in the future but use the Windows32 API (ReadFile et al). libc fds 0,1,2 are handled in a special way on Windows.

Fixed in master.

Pushed a change in master.

Applied.

When the output parameter is given it might even clean up a temporary file on error, but it might also not so we should make sure on a higher level that we check for that and remove it when gpgtar crashes or something like that.

Due to the double fork in gpgme we won't get the exit code which gpgtar emits. Possible actions in a signal handler are also limited; in particular we can't use stdio or estream. The only option to print a status line would we by using write directly. However, this might mess with the libassuan buffering. Thus, it is not a good idea to pkill gpgtar. Same is true for gpg and gpgsm.

I'd prefer "Ablauf Hauptschlüssel" as I don't like "Primärschlüssel". But definitely in two words.

See for T6545 for a new request to support IDP.

We had one request to support this back in 2017 but it was closed because the respective CA stopped using this extension. See T2039.

I found the case of X.509, which also uses fixed length output for RSA-PSS and ECDSA: https://www.rfc-editor.org/rfc/rfc8692.html

The use cases are:

• oPassphraseFD for gpgsm, gpg
• oStatusFD for gpg-auth, gpg-wks-client, gpg-card, gpg-pair-tool, gpgtar, gpgconf, gpgsm, gpg, gpgv
• oLoggerFD for gpgsm, gpg, gpgv
• oAttributeFD for gpg
• oCommandFD for gpg
• oOverrideSessionKeyFD for gpg

Removed parent task because this issue doesn't really block T5478: Kleopatra: Performance problems decrypting and encrypting large Archives.

ready for testing

Done. Can be tested and closed with T5478: Kleopatra: Performance problems decrypting and encrypting large Archives.

ok, then this is resolved

Yes, that was the intention eva reminded me that I had not done this yet, but the next releases of GnuPG VSD will have action/help_contents=false in their action restrictions.

I think that for VSD the Help action is disabled via the configuration because you have alternative documentation to the Kleopatra Handbook. @aheinecke?

Which is the same URL as the F1 Help page thus probably opened via QProcess?

It works, including the nice message box, for most links in the Help menu, but not for the Kleopatra Handbook.

Thank you. Now, I see the reason for conf/ sub directory.