> Ok. Other clients like Evolution and Trojita also had an issue with DNS > prefetching which could be re-enabled in Webkit. Not sure on what library > KMail relies for HTML rending but it might be worth checking that too? > > See https://bugs.webkit.org/show_bug.cgi?id=182924 for the webkit bug (with > links to the Evolution and Trojita ones). KMail using QtWebEngine ( based on Chromium engine) to display content. So far I think it is not affected as it is not listed in the efail paper: https://efail.de/efail-attack-paper.pdf, page 20 > > There are some small patches, that disable this setting for encrypted > > messages, to enforce a user interaction: > > > > https://phabricator.kde.org/D12391 > > https://phabricator.kde.org/D12393 > > https://phabricator.kde.org/D12394 > > > > For me applying the patches makes sense to improve security for users, but > > disabling the external resource loading completely would break workflows. > > Those patches are applied for the following Debian packages, where the > > setting > > is used for everything: > > libmessageviewer5 << 4:18.04.1 > > kmail < 4:18.04.1 > > Thanks, that's good to know. Should I prepare a update with those patches for stable? > > For a more detailed look for KMail and EFail see the dot.kde article: > > > > https://dot.kde.org/2018/05/15/efail-and-kmail > > That article indicates KMail uses GnuPG for S/MIME, which I find a bit > weird. Okay it is simplyfied a lot - but in the end... GPGME itself using gpg-agent etc. to request the work, so in the end it is the normal GnuPG pipeline, that is doing the work, without parsing comandline output :) But for more detailed look I wrote a blog post about the whole crypto stack some while ago: https://exote.ch/blogs/sandro/kontact-and-gnupg-under-windows/ hefee
Attachment:
signature.asc
Description: This is a digitally signed message part.