I agree that "Delete All" should use the same list of attachments as "Save All". Additionally, we should make sure that in both cases the list of attachments that are saved/deleted is identical to the list of attachments that is displayed as attachments in the viewer. Hopefully, KMime::Message::attachments() is also used for this.

Should be fixed.

Using -o signedtext.txt fixes the problem. Unfortunately, gpgme does

      err = add_arg (gpg, "--output");
      if (!err)
	err = add_arg (gpg, "-");
[...]
      if (!err)
	err = add_data (gpg, plaintext, 1, 1);

i.e. it tells gpg to write the output to stdout and then reads everything from stdout as plaintext.

The error was changed to "Bad data" which should be more appropriate.

In T6617#173396, @werner wrote:

What we have here is a clear text signature followed by a public key. If you run this with
gpg -o signedtext.txt --status-fd 2 signedtext.txt should only receive "bar" and not the key listing. If that is not the case something would be very wrong.

This issue should be tested together with T6621: Kleopatra: Remove "in n days/weeks/months/years" input from Change Validity Period dialog.

I have also further unified the handling of the expiration date when

• generating a new OpenPGP certificate
• changing the validity period of an OpenPGP certificate
• certifying an OpenPGP certificate

We now show an error message when the user tries to set an invalid expiration date when changing the expiration date. Additionally,
the configured minimum and maximum validity period is now taken into account, i.e. for changing the expiration now the same rules are applied as for new certificates.

Thanks for the pointer! I'll see how I can do what ecdh_param_str_from_pk does in gpgme.

The relevant logs are

2023-07-27 12:08:01 scdaemon[28156] opgp: ecdh parameters missing
2023-07-27 12:08:01 scdaemon[28156] operation writekey result: Invalid value

I used dbus-monitor to monitor the session bus. I'm seeing the following logged by dbus-monitor when starting kleopatra in the AppImage shell.

method call time=1690445994.197305 sender=:1.141 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
method return time=1690445994.197348 sender=org.freedesktop.DBus -> destination=:1.141 serial=1 reply_serial=1
   string ":1.141"
signal time=1690445994.197368 sender=org.freedesktop.DBus -> destination=(null destination) serial=93 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.141"
   string ""
   string ":1.141"
signal time=1690445994.197394 sender=org.freedesktop.DBus -> destination=:1.141 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.141"
method call time=1690445994.197919 sender=:1.141 -> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.DBus',path='/org/freedesktop/DBus',interface='org.freedesktop.DBus',member='NameAcquired'"
method call time=1690445994.198591 sender=:1.141 -> destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName
   string "org.kde.kleopatra"
   uint32 0
signal time=1690445994.198656 sender=org.freedesktop.DBus -> destination=(null destination) serial=94 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string "org.kde.kleopatra"
   string ""
   string ":1.141"
signal time=1690445994.198680 sender=org.freedesktop.DBus -> destination=:1.141 serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string "org.kde.kleopatra"
[...]

and when quitting Kleopatra I see

method call time=1690446001.636935 sender=:1.141 -> destination=org.freedesktop.DBus serial=21 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=ReleaseName
   string "org.kde.kleopatra"
signal time=1690446001.636978 sender=org.freedesktop.DBus -> destination=:1.141 serial=10 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
   string "org.kde.kleopatra"
signal time=1690446001.636991 sender=org.freedesktop.DBus -> destination=(null destination) serial=97 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string "org.kde.kleopatra"
   string ":1.141"
   string ""

I have just started kleopatra in the shell. Moved it to the background (Ctrl+Z bg). Then started okular. Then opened certificate of signed PDF in kleopatra. Everything works. (Except "Show Signatures Panel" doesn't really work if the side panel is not visible, but that's a completely different issue.) I also tried first starting okular and then kleopatra in the same shell. This also worked.

I cannot reproduce this. Neither with the official AppImage nor with my self-built AppImage. The error message suggests that some process is still registered with DBUS. Maybe a process left over from a previous run?

I had a quick look. gpg --quick-revoke-sig [...] doesn't emit a status message that would tell Kleopatra that the signatures had already been revoked. It just emits a status message telling Kleopatra which key was considered. (Run gpg with --status-fd 2 to see which status messages gpg emits.)

I had a look at this. gpg emits the following status messages:

[GNUPG:] UNEXPECTED 0<LF>
[GNUPG:] FAILURE decrypt 38<LF>

Currently, Kleopatra cannot do anything about this. get_passphrase in protect-tool.c asks those questions and doesn't support a way to give the user more context (e.g. by providing the file name). Once gpg-agent allows giving context, Kleopatra can add for example the file name to the data to import.

I could be wrong, but I think initially we load OpenPGP certificates without signatures, so that we don't know whether the user has certified or revoked a key. Therefore, in the certificate list we cannot decide whether offering the "Revoke" action makes sense. We load the signatures, when the details or the certification dialog is opened.

One complication comes from the fact that gpgmepp and qgpgme include the global config.h that is generated by configure. This needs to be replaced. I'll attach two files where I grepped for usage of the config.h's #defines (generated on Linux) in lang/cpp and lang/qt. The files probably contain false positives.

With the added MIME types Kleopatra now suggests archive (1).tar.gpg as new file name, at least on Linux. Needs to be checked on Windows.

I see little value in viewing emails in Okular. People often want to reply to emails so they need an email client anyway. Or shall Okular get a composer and save the composed email (of course with signing and encryption) to disk so that people can give their reply to their correspondents on a USB stick because that's more secure than using an email server? I suppose it makes sense for spies. ;-)

Thanks! I thought about that when I saw Werner's change in gpg, but would probably have forgotten to actually change it in Kleopatra.

Note: The gpgsm engine of GpgME supports the offline flag (which maps to --disable-dirmngr) only for keylist operations. gpgsm_import doesn't even have an engine_flags argument.

Note that Kleopatra has code that should take care of removing a left-over file. See also T6530#172608.

I'm wondering why I don't see something like

org.kde.pim.kleopatra: slotResult Removing output file ... after error or cancel

in the debug output. It should be output whenever the signing and/or encryption job ended with a non-zero error code and the output file exists. (See commit on 22 June).

Kleopatra should autodetect email messages if passed on the command line or opened via the file dialog. I think Kleopatra should accept any email even if not encrypted. I'm not so sure whether Kleopatra should become an application that offers its service for any email messages if there are proper MIME types for MIME-encrypted or MIME-signed emails.

In T6199#172571, @CarlSchwan wrote:

This will still more work to bring back the massive amount of unit tests. I'm also seriously considering to instead of moving this code to libkleo to instead create a new library with this and then have Kleopatra, kalendar, kube use it (and kmail too in the future but that would require a lot more work).

Ready for testing. I could view a signed PDF and verify the signature with the gpg backend, but other things may not work because of missing dependencies.

It turned out that my pinentry reported "fully canceled" on Cancel (see T6491: Pinentry-Qt: Password prompt for each subkey if password change is cancelled) which made gpg output nothing.

gpg --export-secret-subkeys --armor 704769B8D5C15319A27C74BBB47052506607DA6E confirms that gpg 2.4.1-beta21 outputs nothing if the password entry is canceled.

Of course, it's about right clicking the encryption subkey. That's what I tested. Anyway, cancel wasn't handled properly. Now it is.

Just a quick caveat: Save all attachments works really bad with complex message structures. If we now offer the option to delete all attachments after saving them this could have desastrous effects, i.e. the user could end up with unusable MIME-parts on their disk. I don't remember when I noticed this. Maybe with attached email messages, maybe with signed/encrypted messages, maybe with a combination of both.

The expiry checker checks for expiry. It doesn't and shouldn't do anything else.

I cannot reproduce the problem with Cancel. When I try this, I get the error "The result of the export is empty." and nothing is written to disk. I'm using GnuPG 2.4.

I don't think that Kleopatra allows to select an encrypt-only key for signing because I have fixed exactly this issue a couple of months: T6456: Kleopatra: Offers encryption-only OpenPGP keys as signing key.

I think that's a known issue (or a known non-issue). I ran into this some time ago and therefore added the possibility to start gpg-agent explicitly instead of relying on a keylisting to start the agent implicitly. My guess is that gpg doesn't start gpg-agent because if there are no public keys then it makes little sense to ask gpg-agent for private keys.

Finally, canceling decrypt/verify should also work properly.

Closing since the problem doesn't seem to occur if the operation is canceled properly.

Sorry about that. I tested an old build which didn't call gpgme_cancel_async and therefore probably didn't properly close the channels. It seems to work if gpgme_cancel_async is called to cancel the operation.

This option is already used. Running pgrep -a gpg in a loop (and ignoring gpg-agent processes) I get:

Mo 26. Jun 11:29:11 CEST 2023
19111 gpgtar --batch --status-fd 60 --gpg-args --no-tty --gpg-args --charset=utf8 --gpg-args --enable-progress-filter --gpg-args --exit-on-status-write-error --gpg-args --display=:0 --gpg-args --ttyname=/dev/pts/37 --gpg-args --ttytype=xterm-256color --decrypt --directory /tmp/kleopatra-JqIiXu/src -- /home/ingo/dev/g10/src.tar.gpg
19112 gpg --batch --status-fd=60 --output - --decrypt --no-tty --charset=utf8 --enable-progress-filter --exit-on-status-write-error --display=:0 --ttyname=/dev/pts/37 --ttytype=xterm-256color -- /home/ingo/dev/g10/src.tar.gpg

Argh:

void DecryptVerifyTask::cancel()
{

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