<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Jan 28, 2019 at 10:58 PM Kunal Mehta <<a href="mailto:legoktm@member.fsf.org">legoktm@member.fsf.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Tim wrote a nice blog post about how he reverse-engineered this:<br>
<<a href="https://tstarling.com/blog/2008/12/secure-web-uploads/" rel="noreferrer" target="_blank">https://tstarling.com/blog/2008/12/secure-web-uploads/</a>>.<br>
<br>
I don't have any comments on whether it's still needed, but if it's<br>
determined that MediaWiki can drop the checks, I'd like to see it<br>
turned into a PHP library...mostly because it's some neat code.<br></blockquote><div><br></div><div>Heck yes. :)</div><div><br></div><div>My provisional patch is still keeping the code, but using it more conservatively:</div><div><a href="https://gerrit.wikimedia.org/r/c/mediawiki/core/+/487527">https://gerrit.wikimedia.org/r/c/mediawiki/core/+/487527</a><br></div><div><br></div><div>The exact IE-based heuristics are still checked but will trip only on files matching the exact conditions that would affect old IE versions. Most uploaded JPEG or PNG files with HTML-ish links in EXIF metadata should not trigger it, as the tag strings won't appear in the first 256 bytes of the file.</div><div><br></div><div>The less-exact heuristics (held over from before Tim's addition of the reverse-engineered exact checks) are now less overbearing, and should no longer trigger on <a href, <img, <pre, <table, or <title tags. This also obsoletes the $wgAllowTitlesInSVG setting, which will now be always true.</div><div><br></div><div><br></div><div>Feel free to help with review and testing -- especially welcome if folks have samples of JPEG, PDF, DjVu, or other files that were blocked before but should work so we can double-check. Thanks all!</div><div><br></div><div>-- brion</div><div><br></div></div></div></div></div>