> Evolution probably does not require any changes whatsoever to fix this. This problem is not specific to Evolution; it very probably affects Balsa and Geary at least, and all other applications using WebKitGTK that wish to audit outgoing HTTP requests. The problem is that WebKitGTK is making HTTP requests that bypass its API for blocking HTTP requests, which Evolution relies on.
So, at work, you find out a library you're using is insecure. Do you:
1. Submit a bug report to the library and then do nothing else, for over a year, with no end in sight, and say it's not your problem, you can't fix it, and there's nothing you can do, and you wont tell your users.
2. Address the problem by fixing the library yourself, or getting somebody else to actually fix it, switch to a different library, patch over the problem on your applications side?
If number 1 is your answer, you probably shouldn't be distributing software.
I'll let Balsa and Geary know about the preconnect problem. Will be interesting to see if they take the same awful approach that Evolution Mail did to addressing it.
Andre Klapper went and closed both issues. Presumably he's worried how bad they will look if the devs for either client went and actually addressed this issue instead of passing the buck and doing nothing like Evolution Mail have.
> it very probably affects Balsa and Geary at least
I've just tested, and both fail the link preconnect test but neither fail the dns prefetch test.
So the original bug I posted is on the Evolution Mail side, not the Webkit side. If you go back and look at the thread, you'll see they never actually investigated the issue. They just insisted it wasn't their problem. They were wrong.
They locked the bug of course, because their feelings are more important than distributing secure software to them, so I have no way of informing them of this. They're just pissed they can't lock my blog and that people are finding out about this issue, outside of their control.
Most devs are entirely too casual about making network requests. Do they not share users' expectation that the software won't rat them out to random servers?
Summary: there is a long-standing bug in Webkit which causes network connection from (probably?) any tag that sets a `rel` attribute to be non-auditable and non-blockable by client code using Webkit.
Mike Cardwell stumbled on the manifestation of this bug in Evolution (which uses Webkit for rendering html mail). His proposal was for Evolution to filter html content before passing it to Webkit for rendering. Evolution devs' counterproposal was to ask Mike to write a patch to fix the Webkit bug, so not just Evolution but all other applications built on top of Webkit benefit.
Instead of writing a patch for Webkit (or at least further investigating the Webkit bug), Mike responded by writing two blogposts denouncing Evolution devs.
Evolution devs responded by locking the bug thread and threatening to ban Mike.
This reflects of a failure in security "culture" within the GNOME project. Whether the issue boils down to a bug in WebKit or Evolution code, it is ultimately the Evolution developer's responsibility to not ship an end product with known security issues. Whether that is achieved by changes upstream or in the Evolution project is of no relevance to the end users or general public at large.
> it is ultimately the Evolution developer's responsibility to not ship an end product with known security issues
Is it? One could argue that Evolution developers do not ship an end product, and that it's distros - Debian, Fedora, etc. - who ship the end product by combining Evolution at version X with Webkit at version Y, and possibly patching both.
You use an insecure library in your product, it is your responsibility to deal with that situation yes. You can deal with it by:
1. Fixing the insecure library
2. Getting somebody else to fix the insecure library
3. Switching to a different library that isn't insecure
4. Patching over the problem in your application so that the insecure parts are no longer insecure (Santising and stripping html before passing to Webkit, as many, many other email clients do)
5. Warning the users about the problem (A "do not rely on for privacy" notice next to the feature in the UI, with a link to more info)
Evolution Mail wont do any of this. They don't accept any responsbility for the problem. They submitted a bug report to the library and then sat on their hands. If this is still a problem a year from now, they will still accept no responsbility and still claim there is nothing they can do about it, and their users will still be suffering from the problem with absolutely no knowledge about it.
I find it astonishing that anybody thinks their approach to this is acceptable, or even normal in the software industry. It's totally bizarre.
My blog posts denounced the projects approach to handling security/privacy issues in the software they distribute. They also recommended people stop using the software because it is insecure, and this issue is not being taken seriously by them. My blog posts are 100% factually correct, and I stand by the recommendations.
The fact that some devs took this personally is not my concern.
> Evolution probably does not require any changes whatsoever to fix this. This problem is not specific to Evolution; it very probably affects Balsa and Geary at least, and all other applications using WebKitGTK that wish to audit outgoing HTTP requests. The problem is that WebKitGTK is making HTTP requests that bypass its API for blocking HTTP requests, which Evolution relies on.
https://gitlab.gnome.org/GNOME/evolution/-/issues/3095#note_...
So, at work, you find out a library you're using is insecure. Do you:
1. Submit a bug report to the library and then do nothing else, for over a year, with no end in sight, and say it's not your problem, you can't fix it, and there's nothing you can do, and you wont tell your users.
2. Address the problem by fixing the library yourself, or getting somebody else to actually fix it, switch to a different library, patch over the problem on your applications side?
If number 1 is your answer, you probably shouldn't be distributing software.
I'll let Balsa and Geary know about the preconnect problem. Will be interesting to see if they take the same awful approach that Evolution Mail did to addressing it.
[edit]
- https://gitlab.gnome.org/GNOME/geary/-/issues/1680
- https://gitlab.gnome.org/GNOME/balsa/-/issues/99
Andre Klapper went and closed both issues. Presumably he's worried how bad they will look if the devs for either client went and actually addressed this issue instead of passing the buck and doing nothing like Evolution Mail have.
> it very probably affects Balsa and Geary at least
I've just tested, and both fail the link preconnect test but neither fail the dns prefetch test.
So the original bug I posted is on the Evolution Mail side, not the Webkit side. If you go back and look at the thread, you'll see they never actually investigated the issue. They just insisted it wasn't their problem. They were wrong.
They locked the bug of course, because their feelings are more important than distributing secure software to them, so I have no way of informing them of this. They're just pissed they can't lock my blog and that people are finding out about this issue, outside of their control.
Most devs are entirely too casual about making network requests. Do they not share users' expectation that the software won't rat them out to random servers?
Summary: there is a long-standing bug in Webkit which causes network connection from (probably?) any tag that sets a `rel` attribute to be non-auditable and non-blockable by client code using Webkit.
Mike Cardwell stumbled on the manifestation of this bug in Evolution (which uses Webkit for rendering html mail). His proposal was for Evolution to filter html content before passing it to Webkit for rendering. Evolution devs' counterproposal was to ask Mike to write a patch to fix the Webkit bug, so not just Evolution but all other applications built on top of Webkit benefit.
Instead of writing a patch for Webkit (or at least further investigating the Webkit bug), Mike responded by writing two blogposts denouncing Evolution devs.
Evolution devs responded by locking the bug thread and threatening to ban Mike.
TL;DR drama due to cultural difference.
This reflects of a failure in security "culture" within the GNOME project. Whether the issue boils down to a bug in WebKit or Evolution code, it is ultimately the Evolution developer's responsibility to not ship an end product with known security issues. Whether that is achieved by changes upstream or in the Evolution project is of no relevance to the end users or general public at large.
> it is ultimately the Evolution developer's responsibility to not ship an end product with known security issues
Is it? One could argue that Evolution developers do not ship an end product, and that it's distros - Debian, Fedora, etc. - who ship the end product by combining Evolution at version X with Webkit at version Y, and possibly patching both.
You use an insecure library in your product, it is your responsibility to deal with that situation yes. You can deal with it by:
1. Fixing the insecure library
2. Getting somebody else to fix the insecure library
3. Switching to a different library that isn't insecure
4. Patching over the problem in your application so that the insecure parts are no longer insecure (Santising and stripping html before passing to Webkit, as many, many other email clients do)
5. Warning the users about the problem (A "do not rely on for privacy" notice next to the feature in the UI, with a link to more info)
Evolution Mail wont do any of this. They don't accept any responsbility for the problem. They submitted a bug report to the library and then sat on their hands. If this is still a problem a year from now, they will still accept no responsbility and still claim there is nothing they can do about it, and their users will still be suffering from the problem with absolutely no knowledge about it.
I find it astonishing that anybody thinks their approach to this is acceptable, or even normal in the software industry. It's totally bizarre.
My blog posts denounced the projects approach to handling security/privacy issues in the software they distribute. They also recommended people stop using the software because it is insecure, and this issue is not being taken seriously by them. My blog posts are 100% factually correct, and I stand by the recommendations.
The fact that some devs took this personally is not my concern.