28.12.08

One reason why Mozilla doesn’t use platform libraries

Tags: , , , , , — Jeff @ 14:02

Every so often (okay, ALL THE TIME) someone (Linux users, of course :-) ) wonders why Mozilla doesn’t use platform libraries for things like networking code. One commonly-argued reason is that it gives us the flexibility to fix security problems without waiting on those upstream libraries to make the fix themselves — we control the code, and we can make the fixes ourselves.

Another reason not to use platform libraries occurred to me while reading Planet WebKit today, specifically the recent WebKit’s week – #7 post. Quoting from that post, added emphasis mine:

HttpOnly Cookie (38566)

An Internet Explorer extension (added in Firefox and Opera since) will soon be supported by WebKit based browsers. This restricts the access to certain cookies. They are only available for an HTTP request and so not from JavaScript. This is an important functionality to restrict the damages of an XSS vulnerability. This is not available in the nightlies because you need some updated Apple proprietary libraries (CFNetwork).

As noted, Firefox supports HTTPOnly cookies; after the patch to add this support was committed, you could download nightly builds which included the fix, and HTTPOnly would Just Work. No mess of upgrading platform libraries to make it happen, no separate-package updating, no waiting on Apple to update their platform libraries. (Incidentally, will Apple make those updates for 10.4 users as well, assuming they even decide to release a browser upgrade for a, er, “dying” OS release? Maybe, maybe not, who can say; “Apple does not comment on future products.”) Just download the build, build it from source yourself if you like building from source or if you’re a Gentoo ricer, and you have a working browser with the fix.

There are tradeoffs to be made rolling your own code when you could use something provided by the OS or by a third-party library. However, it should be equally clear that there are tradeoffs to be made going the other way, at least if you truly care about being cross-platform.

(On an almost entirely unrelated note, I was pleased to discover while writing this post that HTML5‘s outline-generation algorithm properly handles headings inside blockquote elements. Yay for specs anticipating my concerns! :-D )

2 Comments »

  1. For that matter, why doesn’t Mozilla just use Webkit. Or vice-versa.

    [Others have already addressed that, and it’s not really what I was addressing anyway, so I’ll leave that question alone.]

    Comment by Sean Hogan — 28.12.08 @ 15:15

  2. So, is this fix provided upstream? If yes – I can install new lib version. I no – FFFFFFFFUUUUUUUUUUUUUuuuuuuuuu!

    You’re using opensource libs, so you can provide fixes to upstream and still provide bundled libs. It’s not about apng & libpng/unmaintained lcms1. It’s about cairo, libjpeg, libbz2 etc etc etc etc..

    It’s really hard to maintain Fx/Tb packages.

    [Um, I’m pretty sure we do upstream fixes for imported libraries. See, for example, gfx/cairo/win32-composite-src-mod.patch and the associated bug (also comment 33 there too), concluding in a cairo commit upstream. That sort of thing goes away when cairo is upgraded, which is not a particularly trivial modification, not given the incredible variety of ways we use cairo that most projects don’t. Generally an upgrade to the cairo in Mozilla involves several rounds of bustage fixes as we discover things the new cairo breaks, sometimes our fault, sometimes not. That’s a lot of the reason it’s not really possible to just use the upstream cairo all the time; having disparate rendering based on the distribution’s installed cairo version would Break the Web, and that’s not good.

    This is still not quite what I’m talking about, tho, in that you’re concerned about code we borrow from elsewhere, while I was more pondering code we would use from elsewhere and not bundle ourselves. Your scenario doesn’t have the problem of waiting on upstream/OS/etc. for fixes (the fundamental issue I raise), while mine does.

    I’m not going to get started on a rant about how the Linux packaging system basically requires all application distribution be brought in-house to really work, or that distro fragmentation requires packaging numerous times for different distros, and that distros provide much of their value by eliminating third-party distribution. Really, I’m not. Really.]

    Comment by ojab — 29.12.08 @ 09:23

RSS feed for comments on this post. TrackBack URI

Leave a comment

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>