Some MUAs such as Thunderbird (via the Enigmail plugin) have implemented some protection against metadata leakage in GPG. One of them is called "protected-headers" and embeds the original subject line in a PGP/MIME message. When an e-mail is decrypted, the original title is recovered from these data. Claws Mail does not support this at the moment so GPG messages with protected headers usually show the subject line "Encrypted message". Please see - https://github.com/autocrypt/memoryhole - https://trac.torproject.org/projects/tor/ticket/21880 for details. Apart from the subject line, this bug has no effect on GPGs functionality at all, but it would be nice to see it implemented.
Please also see: https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4426 for a related issue.
AFAIK, so-called "protected-headers" breaks the standard.
You may be right, they used to be a IETF draft which expired May 7, 2020. [1]: https://tools.ietf.org/id/draft-autocrypt-lamps-protected-headers-01.html Nonetheless they are implemented in certain Clients "This document defines a scheme, “Protected Headers for Cryptographic E-mail”, which has been adopted by multiple existing e-mail clients in order to extend the cryptographic protections provided by PGP/MIME to also protect the message headers." [1] I'll be going to ask D. Gilmor on some background information on this draft and whether it has been withdrawn for good reasons (contradicting a standard) or just not been finished in time.
I second this feature request strongly. More and more people communicate with encrypted emails, and I see a lot of subjects just as `...`. Which makes it more and more hard to look through my emails. At the end it might me force to change email client if claws mail will not support it. I have manually looked into such a message; the OpenPGP ecrypted part (i.e. the stuff enclosed in -----BEGIN PGP MESSAGE----- -----END PGP MESSAGE----- ) contains, if decrypted, some headers, e.g. the original subject. If I view that Email in claws mail, it does strip away those headers (so claws actually _does_ interpret the decrypted part somehow) and shows only the rest of the plain text. For reference, here how such a manually-on-the-command-line gpg-decrypted part of such a message looks like (sensitive information I have replaced with '[censored]'): Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XfvnKHsOtfHkXadLkFCRmhnTSag7EX303" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XfvnKHsOtfHkXadLkFCRmhnTSag7EX303 Content-Type: multipart/mixed; boundary="8ebV6epa0RTRRbo103dXDdKga9VibzbwV"; protected-headers="v1" Subject: Re: Post von [censored] From: [censored] To: [censored] Message-ID: <67[censored]@[censored]> References: <2021[censored]@[censored]> In-Reply-To: <2021[censored]@[censored]> --8ebV6epa0RTRRbo103dXDdKga9VibzbwV Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi [censored], [censored] Regards, [censored] --8ebV6epa0RTRRbo103dXDdKga9VibzbwV-- --XfvnKHsOtfHkXadLkFCRmhnTSag7EX303 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- [censored] -----END PGP SIGNATURE----- --XfvnKHsOtfHkXadLkFCRmhnTSag7EX303--
Dear Felix, I have started a development endeavour to prepare a fix/feature for this. you may want to visit https://github.com/ahngoo8Gongi/claws-mail/tree/protected-headers in order to see what I did so far. At least after selecting the message, the protected headers should be displayed. Not yet in the header preview, though, neither verified in the full view. Regards Holger
.. if people are reluctant to include it into claws mail due to unclear standards, it might be an option to include "protected headers support" as plugin?
@Holger: Thanks for that. I tried to build it (just `./autogen.sh`, `./configure`, `make`), but it fails for me in `make` on some version stuff: ``` /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../intl -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/valgrind -DLOCALEDIR=\""/usr/local/share/locale"\" -DPLUGINDIR=\"/usr/local/lib/claws-mail/plugins/\" -DDATAROOTDIR=\""/usr/local/share"\" -DDESKTOPFILEPATH=\"/usr/local/share/applications/claws-mail.desktop\" -DGTK_DISABLE_DEPRECATED -g -O2 -Wno-unused-function -Wno-pointer-sign -Wall -D_GNU_SOURCE -MT claws.lo -MD -MP -MF .deps/claws.Tpo -c -o claws.lo claws.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../intl -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/valgrind -DLOCALEDIR=\"/usr/local/share/locale\" -DPLUGINDIR=\"/usr/local/lib/claws-mail/plugins/\" -DDATAROOTDIR=\"/usr/local/share\" -DDESKTOPFILEPATH=\"/usr/local/share/applications/claws-mail.desktop\" -DGTK_DISABLE_DEPRECATED -g -O2 -Wno-unused-function -Wno-pointer-sign -Wall -D_GNU_SOURCE -MT claws.lo -MD -MP -MF .deps/claws.Tpo -c claws.c -fPIC -DPIC -o .libs/claws.o In file included from claws.c:42: claws.c: In function ‘claws_get_version’: version.h:32:54: error: ‘a7336c’ undeclared (first use in this function) 32 | #define VERSION_NUMERIC MAKE_NUMERIC_VERSION(a7336c, a7336c, \ | ^~~~~~ version.h:25:54: note: in definition of macro ‘MAKE_NUMERIC_VERSION’ 25 | #define MAKE_NUMERIC_VERSION(a, b, c, d) ((((guint32)a) << 24) | (((guint32)b) << 16) | \ | ^ claws.c:143:16: note: in expansion of macro ‘VERSION_NUMERIC’ 143 | return VERSION_NUMERIC; | ^~~~~~~~~~~~~~~ version.h:32:54: note: each undeclared identifier is reported only once for each function it appears in 32 | #define VERSION_NUMERIC MAKE_NUMERIC_VERSION(a7336c, a7336c, \ | ^~~~~~ version.h:25:54: note: in definition of macro ‘MAKE_NUMERIC_VERSION’ 25 | #define MAKE_NUMERIC_VERSION(a, b, c, d) ((((guint32)a) << 24) | (((guint32)b) << 16) | \ | ^ claws.c:143:16: note: in expansion of macro ‘VERSION_NUMERIC’ 143 | return VERSION_NUMERIC; | ^~~~~~~~~~~~~~~ claws.c:144:1: warning: control reaches end of non-void function [-Wreturn-type] 144 | } | ^ make[5]: *** [Makefile:780: claws.lo] Error 1 make[5]: Leaving directory '/[...]/claws-mail-gtk2-protectedheaders-git/src/claws-mail/src/common' make[4]: *** [Makefile:820: all-recursive] Error 1 make[4]: Leaving directory '/[...]/claws-mail-gtk2-protectedheaders-git/src/claws-mail/src/common' make[3]: *** [Makefile:1655: all-recursive] Error 1 make[3]: Leaving directory '/[...]/claws-mail-gtk2-protectedheaders-git/src/claws-mail/src' make[2]: *** [Makefile:1337: all] Error 2 make[2]: Leaving directory '/[...]/claws-mail-gtk2-protectedheaders-git/src/claws-mail/src' make[1]: *** [Makefile:794: all-recursive] Error 1 make[1]: Leaving directory '/[...]/claws-mail-gtk2-protectedheaders-git/src/claws-mail' make: *** [Makefile:568: all] Error 2 ``` .. Maybe you can make your changes available as single patches which can be patched against the official sources?
Hi Felix, apologies for any inconvenience in regard to building from my repo. Works for me. Can you build claws from the stock repo? At least I didn't change claws.c, nor version.h and wonder why this build error should occur. Feel free to provide code for the protected-headers plugin. I won't mind, if you'll be faster than I. Regards, Holger
Dear Felix, apparently your version.h file has been build incorrectly from version.h.in.
Created attachment 2235 [details] preliminary patch, for verification and review in regard to architecture/style Attached a patch which should apply (with -p1, though) to the most recent status of main. Patch includes - delayed display of Headers in messageview until protected-headers have been parsed - indication whether protected header could be verified or was changed - storing protected headers in msginfo structure for later re-use Could you kindly review in regard to architecture/style and function with your use cases?
Created attachment 2236 [details] preliminary patch, for verification and review in regard to architecture/style revised patch to apply with -p0
found, that this patch does not correctly handle the non-conforming way of firefox/enigmail to protect headers, but only the one of the IETF draft. Will rework patch to cover firefox/enigmail way.
Created attachment 2239 [details] next debug patch, collecting all protected headers... Another revised patch for review,testing and comments.
Comment on attachment 2236 [details] preliminary patch, for verification and review in regard to architecture/style obsoleted previous patch as is is replaced by new testing patch.
I just wanted to dry again; the patch from 2021-08-10 fails to apply to current claws mail git checkout: ``` checking file AUTHORS checking file src/messageview.c Hunk #1 succeeded at 1416 (offset 6 lines). checking file src/plugins/pgpmime/pgpmime.c checking file src/privacy.c checking file src/procheader.c Hunk #1 succeeded at 58 (offset -4 lines). Hunk #2 FAILED at 73. Hunk #3 succeeded at 78 (offset -4 lines). Hunk #4 succeeded at 138 (offset -4 lines). Hunk #5 FAILED at 164. Hunk #6 succeeded at 178 (offset -4 lines). Hunk #7 succeeded at 205 (offset -4 lines). Hunk #8 succeeded at 256 (offset -4 lines). Hunk #9 FAILED at 386. Hunk #10 succeeded at 404 (offset -4 lines). 3 out of 10 hunks FAILED checking file src/procheader.h checking file src/procmime.c Hunk #1 succeeded at 969 (offset 6 lines). Hunk #2 succeeded at 1401 (offset 10 lines). Hunk #3 FAILED at 1441. Hunk #4 succeeded at 1464 (offset 10 lines). Hunk #5 FAILED at 1486. Hunk #6 FAILED at 1656. Hunk #7 succeeded at 2009 (offset 10 lines). Hunk #8 succeeded at 2034 (offset 10 lines). Hunk #9 succeeded at 2135 (offset 10 lines). Hunk #10 succeeded at 2198 (offset 10 lines). 3 out of 10 hunks FAILED checking file src/procmime.h checking file src/procmsg.c Hunk #1 succeeded at 815 (offset 22 lines). Hunk #2 succeeded at 1485 (offset 22 lines). Hunk #3 succeeded at 1573 (offset 22 lines). checking file src/procmsg.h checking file src/textview.c Hunk #1 succeeded at 192 with fuzz 2 (offset 12 lines). Hunk #2 succeeded at 638 (offset 26 lines). Hunk #3 succeeded at 659 (offset 26 lines). Hunk #4 succeeded at 678 (offset 26 lines). Hunk #5 succeeded at 718 (offset 26 lines). Hunk #6 succeeded at 814 (offset 26 lines). Hunk #7 succeeded at 1059 (offset 26 lines). Hunk #8 succeeded at 2283 (offset 27 lines). Hunk #9 succeeded at 2364 (offset 27 lines). checking file src/textview.h ```
Dear Felix, apologies for not having posted patches for a while. I had issues keeping the patches current. Now I have patch working for the structure implementing the IETF draft, but the thunderbird/enigmail and thunderbird native format still doesn't work as expected.
Dear Felix, find an updated patch attached to https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4426 Note, it does only solve the problem fot messages protective headers according to the IETF draft, not yet for thunderbird/enigmail
> apologies for any inconvenience in regard to building from my repo. For your information: It is now reported at https://github.com/ahngoo8Gongi/claws-mail/issues/3. See also https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4426#c24..
*** This bug has been marked as a duplicate of bug 4426 ***
Any progress in adding protected headers support for enigmail flavour and properly integrating it to claws mail upstream/ providing a patch that applies to the latest 3.19/ 4.1 release?
Any progress in adding protected headers support for enigmail flavour and properly integrating it into official claws mail?