We had to add the parameters because some keys don't use the default paramters PGP and gpg have used since the introduction of ECC 12 years ago. So yes, we could fallback to the standard parameters but it would bet better if Kleopatra could extract them from the public key (maybe via a GPGME helper).

I won't go so far to try to fully implement RFC2231 in the rfc822parse. But I have an idea how to implement this in a secure and robust manner in rfc822parse without touching the parser or the token stuff. My idea is to treat them as seperate TOKEN and then combine them in query parameter just for name and filename values.

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

That assumes that libtool won't change substantially as it did several times in the past and broke our cross compiling stuff. But as long as we keep the ltmain.sh in our repo and tarball the patch is okay because it better documents the chnages.

It's a shell issue. With bash Kleopatra starts from the shell. Andre will debug further.

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 learned that AC_CONFIG_COMMANDS macro can be used to improve the case of config.status.

How about the change like:

this is not true. Our installers are always signed, even the included binaries are mostly signed.

Other options would be

• to display a warning if there are inline images in the email.
• an option not to automatically sign emails if they contain an inline image.

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.

Right, I had briefly uploaded a "GnuPG-Desktop" appimage but then realized that for the gnupg.org download site the "GnuPG-Foo" was actually the correct version. Werner and me discussed the future of that version and there will be some changes for future releases which I won't go in there. But functionally it is the same, only the VERSION file differs.

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>

As described, the storage location is now shown per subkey in the subkey details window.

works

works as described.

How about giving a notification in Kleopatra relaying gpgs message(s) "signature already revoked"? Instead of ~"3 certifications were successfully revoked, do you want to publish them?"

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.

works. Certificates are shown in alphabetical order to the user and expired subkeys are ignored for encryption even if they are newer.

From my side this can be closed. In Kleopatra we can maybe check for some more MIME types and then use GPGME_ENCRYPT_NO_COMPRESS but that is unreleated.

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.

works as described. But If you already have revoked one or all certifications of that key, you still get the revocation dialog.

works

I found the rfc https://datatracker.ietf.org/doc/html/rfc2231.html the code to decode this is not fun and can be found here: https://invent.kde.org/frameworks/kcodecs/-/blob/master/src/kcodecsqp.cpp

@ikloecker I think your logs contain only false positives, I do not know that we use any defines created by config.h. Maybe for gpgme_off_t but even so when I moved gpgme++ and qgpgme from kdepimlibs into the GPGME repo I did not add any defines to configure for that.

Fixed with c6e16e403744ca39a24a38f38264865019c0cb93

Hi Carl,
yes I saw that test case. Btw. I don't really think that this comes from Outlook itself otherwise I would have seen this much earlier, the current MIME Parser in our Outlook Plugin is about 8 years old. Currently this comes through some kind of AppleMail (server?) application to the customer.

Applied to master.

Applied to 2.4.

Applied to master.

To be honest I have never seen such a way to transfer parameters but KMime and our new MIMETreeparser in T6199 can probably handle them but our old and trusty RFC822parse code in GpgOL needs to be adjusted.