4 ms·

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

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.

veeti 1y ago
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.
- tetromino_ 1y ago
  > 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.
  - mike-cardwell 1y ago
    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.
    - deleted 1y ago
      [deleted]
mike-cardwell 1y ago
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.

veeti 1y ago

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.

tetromino_ 1y ago
> 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.
- mike-cardwell 1y ago
  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.
  - deleted 1y ago
    [deleted]

mike-cardwell 1y ago

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.