My previous blog post seems to have resolved most concerns about my requests for Ubuntu stable release updates, but I again received rather a lot of criticism for the choice to make WebKit depend on OpenJPEG, even though my previous post explained clearly why there are are not any good alternatives.
I was surprised to receive a pointer to ffmpeg, which has its own JPEG 2000 decoder that I did not know about. However, we can immediately dismiss this option due to legal problems with depending on ffmpeg. I also received a pointer to a resurrected libjasper, which is interesting, but since libjasper was removed from Ubuntu, its status is not currently better than OpenJPEG.
But there is some good news! I have looked through Ubuntu’s security review of the OpenJPEG code and found some surprising results. Half the reported issues affect the library’s companion tools, not the library itself. And the other half of the issues affect the libmj2 library, a component of OpenJPEG that is not built by Ubuntu and not used by WebKit. So while these are real security issues that raise concerns about the quality of the OpenJPEG codebase, none of them actually affect OpenJPEG as used by WebKit. Yay!
The remaining concern is that huge input sizes might cause problems within the library that we don’t yet know about. We don’t know because OpenJPEG’s fuzzer discards huge images instead of testing them. Ubuntu’s security team thinks there’s a good chance that fixing the fuzzer could uncover currently-unknown multiplication overflow issues, for instance, a class of vulnerability that OpenJPEG has clearly had trouble with in the past. It would be good to see improvement on this front. I don’t think this qualifies as a security vulnerability, but it is certainly a security problem that would facilitate discovering currently-unknown vulnerabilities if fixed.
Still, on the whole, the situation is not anywhere near as bad as I’d thought. Let’s hope OpenJPEG can be included in Ubuntu main sooner rather than later!
Well, it’s premature to discard JPEG 2000 decoder provided by ffmpeg based on legal issues. Legal issues only affect other code in ffmpeg. Nothing, in theory, prevents you from extracting this one decoder and making it standalone, just like PulseAudio did with the ffmpeg audio resampler. They even have scripts to resync the code from ffmpeg, should any issues arise (but chances are that these scripts no longer work).
OTOH, the review of the review of OpenJPEG is indeed a good news.
Well yes, of course we could do that, but then we have to maintain it somewhere! (Probably in WebKit.) OpenJPEG is a better option.
What issues do you have with depending on ffmpeg? Most of it’s codecs are out of patent, and when built correctly it just handles free ones. Google depends on it for chrome.
Sounds to me you are stuck with using an unstable library and trying blame Ubuntu for it.
Amir, don’t be a Ubuntu fanboy, turn off the blinders and actually read the post. Nothing about it indicates that it is an unstable library
Care to explain why you insist it is important to have this problem in the first place? A user-agent isn’t “fragile”. You can easily change it and not pretend to be something you’re not. Of course you’d need a browser name and not just “Web” as Epiphany’s now re-named but it would be fine if you change the name back to something more than the program’s function.
Firefox doesn’t break if you change the user-agent string with general.useragent.override. Some websites will make assumptions based on the user-agent, if it claims “Mobile” serves are going to assume it’s a phone. If you claim “Safari” servers are going to assume you’re safari or compatible with it. There’s no need to claim you’re compatible with Safari. “Mozilla/5.0 (compatible; GnomeWeb)” would do just fine. There’s no reason it has to be “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Safari/605.1.15 Epiphany/605.1.15”. But if there is then feel free to explain why you think so.
“There’s no need to claim you’re compatible with Safari. “Mozilla/5.0 (compatible; GnomeWeb)” would do just fine.”
So innocent. :)
Look over the change history of UserAgentQuirks.cpp, UserAgentGLib.cpp, and the old UserAgentGtk.cpp. I’ve spent too many days agonizing over how to make our user agent web-compatible, and learned from both my previous mistakes and the mistakes of those who handled the user agent before me. It is ludicrously fragile and should only be touched with extreme trepidation.
See this mailing list thread for the most recent example of serious trouble, which fortunately ended well enough (nowadays the only quirk we need for Google is a Linux platform quirk). There are more old links I could dredge up. Before I managed the user agent, other developers made the mistake of trying to use a Mac user agent, or a Chrome user agent. Nowadays we know better.