
<html><head></head><body>Hello Gerv,<br>

<br>

such an analysis tasks time, the last report i made took hours. i cannot remember the details, and I'd have to look through the list again.<br>

<br>

keep in mind that gecko is not only a rendering engine. XPCOM is also a OS class library with many implementations, from string classes up to DNS. any bug anywhere there would affect Thunderbird just a well, even without rendering.<br>

<br>

i cannot remember the concrete bugs, though. it were enough that i concluded that avoiding rendering does not entirely solve the issue.<br>

<br>

if you are really interested, for a rough approximation, you can look through the MFSA (Mozilla security advisories), which link the relevant bugs (of older releases, but that makes no difference, as we're only interested in bug classes, not live examples). <br>

<br>

of course your can always try to backport the fixes, with a lot of effort. but only up to a certain point. if you cannot, you're toast.<br><br><div class="gmail_quote">Am 5. Februar 2018 18:09:24 MEZ schrieb Gervase Markham <gerv@mozilla.org>:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">On 05/02/18 11:30, Ben Bucksch wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> no, i mean there are low-level platform security bugs that will be<br /> exposed by thunderbird processing network data. not rendering, but<br /> lower. there are more of those than i thought.<br /></blockquote><br />When you get a chance, please provide a concrete example, and show how<br />if we forked and froze Gecko, this would be a bug one could trigger both<br />in Firefox and Thunderbird, and Firefox's patch would be unusable to us<br />due to code change.<br /><br />Gerv<br /></pre></blockquote></div><br>

-- <br>

Sent from my phone. Please excuse the brevity.</body></html>