We are getting closer to kill old and vulnerable webkit-gtk versions... but for that we would need to kill its optional dep from here :/
Thanks a lot
Author: Lars Wendler <firstname.lastname@example.org>
Date: Wed Feb 8 11:43:42 2017
mail-client/claws-mail: Revbump to remove webkit support (bug #608612).
Package-Manager: Portage-2.3.3, Repoman-2.3.1
Keeping this bug open until all claws-mail ebuilds using webkit have been removed.
This requires stabilization of the now revbumped ebuild first.
Is there (or will there be) another way to display HTML mail?
Please do not drop the latest webkit version until there is a substitute,
we depend on html mail.
Latest webkit version of claws mail was 3.14.1,
which was dropped from portage this week.
Now I have to downgrade to 3.13.2, which re-introduces old bugs
and makes the security situation worse, not better.
1.) By default, webkit is run in local mode by claws mail,
i.e. it is only allowed to access local files (the html part of the mail),
no ressources on the internet. Only after explicitely clicking
"enable remote content", webkit is allowed to access remote content.
i.e. no active contents at all, just plain html, even if remote content
Hence, the security risks of running webkit within claws are absolutely
minimal as long as you do not click on the "enable ..." buttons.
2.) Upstream has re-enabled the dillo plugin in 3.15.0 as an alternative
to webkit. However, the gentoo 3.15.0 ebuild does not support dillo.
Please at least leave the most recent webkit versions in the portage tree
until claws dillo support has been stabilized!
Just need to add a webkit or other use flag and enable the fancy plugin for HTML. I edited the ebuild, changed the hard coded --disable-fancy to --enable-fancy, re-digested, emerged and works fine. I was about to file a bug requesting such when I came across this one.
Can we please move this along? 3.14.1 or 3.15.0 needs stabilizing and 3.13.2 removed from tree. I don't know what other options there are in claws for HTML mails, but I keep hearing something about a dillo based one until they can get ported to gtk3 and webkit-gtk:4.
It is irresponsible to still easily subject our users to hundreds of security bugs, out of which a good handful are probably easily exploitable via HTML mail, as it's not about just showing local HTML help or whatnot in case of claws-mail.
(In reply to Mart Raudsepp from comment #5)
> Can we please move this along? 3.14.1 or 3.15.0 needs stabilizing and 3.13.2
> removed from tree. I don't know what other options there are in claws for
> HTML mails, but I keep hearing something about a dillo based one until they
> can get ported to gtk3 and webkit-gtk:4.
I was told that the dillo plugin has been re-added to the claws git tree,
but has not been included in any 3.14 or 3.15 release
because it is unmaintained and not considered stable and supported.
> It is irresponsible to still easily subject our users to hundreds of
> security bugs, out of which a good handful are probably easily exploitable
> via HTML mail, as it's not about just showing local HTML help or whatnot in
> case of claws-mail.
Hmmm, I'm not sure which is worse w.r.t. security:
The vulnerable webkit plugin in strictly local-only mode
(which is the default in Claws),
or calling an external browser (firefox, ...) in non-local mode
As long as there is no strictly local-only active-content-off mode
for firefox, chromium etc. (and as far as I know,
there is no such mode or command line option for them),
I'd prefer a vulnerable, but strictly restricted webkit
(and the really paranoid could disable all embedded graphics, too).
Well, as soon as you use a security supported external browser... I think it will be safe enough for sure :/ And you will also save from building old webkit-gtk only for one app, and it is really costly on compile time
I'm pretty sure a good handful of these security bugs would have absolutely nothing to do with JS, active content or whatnot, but exploitable with JS and that active-content-whatever disable too. I mean, there's like 300+ unpatched CVEs for webkit-gtk-2.4...
(In reply to Mart Raudsepp from comment #8)
> I'm pretty sure a good handful of these security bugs would have absolutely
> nothing to do with JS, active content or whatnot, but exploitable with JS
> and that active-content-whatever disable too. I mean, there's like 300+
> unpatched CVEs for webkit-gtk-2.4...
From a security point of view, you are correct.
From a practical point of view:
When I call an external browser in non-local mode,
it is most likely a commonly-used browser,
and any attacker immediately finds out which browser and platform
I use and can deliver exploits targetted to that browser.
At least, the sender of the mail can track that I've read the mail,
gets my real IP address and some information about my platform,
can set cookies and track me, and so on. And he can link my mail address
to my browsing footprint and history on the internet,
because mail and browsing use the same browser with the same fingerprint.
When I read mails with built-in local-mode webkit,
an attacker does not get any information at all which web engine
and platform I use. So, he would have to send exploits blindly,
and those exploits would be suitable for perhaps one recipient
out of a million (how many of all internet users use claws
with webkit on linux?). This simply does not pay off for attackers,
it's not an attractive target...
And I greatly appreciate that the local-only webkit does not give
the sender any hint that I've read the mail, that I use linux, etc.,
and does not allow the sender to track me in any way, or to set cookies.
Keeping the mail web engine and the browsing web engine separate
has its benefits w.r.t. privacy (in fact, in my installation
these two engines run within two strictly separated users).
Don't get me wrong:
Of course, I'm interested in having the current situation improved.
However, I don't want the current webkit solution to be dropped
before there is an equivalent solution (local-only active-off mode
for security and for privacy, nicely integrated into claws).
You really need to arrange help for upstream to get gtk3 porting finished and porting to webkit2gtk API then.
WebKit2GTK+ API has been available since 2.4 (yes, that same version we are stuck to, it was still providing both old and new API, old was dropped by 2.6), which has been available for over 3 years, with it known what old API will be dropped in the next cycle.
GTK+3 has been available for over 6 years, with it known that GTK+2 will not be maintained anymore at some point and various libraries (like webkitgtk) are bound to drop gtk2 support sooner or later. In practice GTK2 is not maintained for a while now.
We can not keep around security vulnerable stuff (hundreds of vulnerabilities) because of a slow project that can't get things done in 3-6+ years. I have my webkit-gtk gentoo maintainer had on for this claim, and we need this finally done, at least for remote things at first (yes, claws-mail IS remote attack vector in terms of traditional security terminology, not local - it downloads HTML mail for display from uncontrolled remote sources).
I totally get the security argument and that this needs to be fixed upstream. But ...
As much as i dislike html mails a lot of people still want to able to display them in a somewhat readable way. The way claws-mail renders them without the fancy plugin is IMHO not readable.
Is there a way to allow brave and ignorant users to still enable the plugin? I mean a USE-flag that would trigger a big warning in elog or require an "i do not care" setting in /etc/portage?
I guess masking the required libs for security reasons and keeping the USE-flag would do the trick. And keeping the problematic lib in tree until there is another html rendering thing for claws-mail.
That would require anyone setting the USE-flag to explicitly unmask the problematic lib.
webkit-gtk-2.4 will be removed from tree once it doesn't break tree dependnecy tree, not p.masked. No long term p.mask tricks will be done by the webkit-gtk maintainers. Sorry.
If upstream isn't able to still get gtk3 version and webkit2gtk port done, maybe should help out (helping with code; feature targeted donations, or whatever they happen to like), or consider it too badly upstream developed for continued usage.
Main claws gtk3 bug (also for fancy / webkit plugin update):
All versions that had webkit support were gone with the following commit:
commit a05e9f9339cc6b381226d5b3faa4f3ea7455652a (HEAD -> master, origin/master, origin/HEAD)
Author: Lars Wendler <email@example.com>
Date: Sun Dec 17 20:44:18 2017
mail-client/claws-mail: Removed old.
Package-Manager: Portage-2.3.19, Repoman-2.3.6
mail-client/claws-mail/Manifest | 2 --
mail-client/claws-mail/claws-mail-3.13.2.ebuild | 187 ------------------------------------------------------------------------------------------------------------------------------------------------
mail-client/claws-mail/claws-mail-3.14.1-r1.ebuild | 197 --------------------------------------------------------------------------------------------------------------------------------------------------------
mail-client/claws-mail/metadata.xml | 2 --
4 files changed, 388 deletions(-)
Created attachment 511004 [details, diff]
Patch for ebuild
The resolution/fix is not worth the noise, as you simply suppress the use of the fancy plugin through USE flags. Attached patch changes that back, as currently no real fix for reading HTML mails with claws-mail exists - if one wants to use it, please preserve a copy of webkit (ebuild and tar file).