I rewrote Firefox's BMP decoder
blog.mozilla.org
blog.mozilla.org
Note especially the two bugs listed in the "Blocks" field, which are the first two candidates for components to be rewritten once the build system issues are sorted out. (The second of these would replace the notoriously insecure libstagefright with a Rust alternative.)
Piston has a BMP decoder, and my understanding is that it is the one used by Servo. I looked at it briefly and I think its support for the dark corners of the BMP format would be even worse than Firefox's would be before my rewrite. See https://github.com/PistonDevelopers/image/tree/master/src/bm... for the code.
It seems unfortunate to be maintaining two BMP decoders because of transient build system issues. Especially if we're going to have to rewrite Piston's, making us maintain three for a time. I understand if there was some pressing need to ship it now, of course, but other than that I think I would have preferred this be written in Rust as well.
I guess it's not a big deal for 1,000 lines of code, though. We could probably do a line for line translation without much effort.
But this is about more than just transient build system issues. If we want to completely replace C/C++ components with Rust components, rather than just having them co-exist, then we need to make Firefox have a hard dependency on Rust. I suspect I'm a lot more pessimistic than many people about when we can do that; to me it feels like something that is multiple years away. I'd be interested to hear how long you think it will take!
I guess I had an implicit assumption—which may be wildly false—that maintaining the old BMP decoder wouldn't be too much of a burden. If it is a huge burden, then it would make sense to rewrite it now in C++. Otherwise, thinking long-term, I think it would make sense to rewrite in Rust, trading short-term bug fixes for improved memory safety in the future and less work overall (since you save one rewrite).
(Again, though, since we're talking 1,000 lines of code of something that's probably line-for-line-translatable either way; I don't think it's a big deal.)
Sure, easier to use a library, but sometimes you have some constraints
[1] https://en.wikipedia.org/wiki/Netpbm#PAM_graphics_format
http://www.dca.fee.unicamp.br/~martino/disciplinas/ea978/tga...
The only real alternative to it (== simple uncompressed bitmaps) that I can think of are .tga files, but these haven't penetrated the Internet as well as BMP has.
Also - all code exposes security risks. Especially image decoders written in C/C++.
Because they're incredibly easy to generate programatically. For example, here's a bunch of experiments I did to test the code and image embedding process for my site:
http://chriswarbo.net/essays/procedural
The snippets of Haskell code on those pages are executed when the page's Markdown is rendered, and the images are the results. To make this work, each function maps x and y pixel coordinates to either a Bool (for b/w), an Int (for greyscale) or an (Int, Int, Int) tuple (for RGB). These are trivially converted into strings of PPM image data (via [1]), rendered to PNG (via [2]) and embedded into the page as a data URI (via [3]). The "view source" links show all the code, although it's a bit convoluted ;)
Whilst this example is just for experimentation, I could image someone generating raw bitmaps in a monitoring situation, for example.
[1] http://chriswarbo.net/git/chriswarbo-net/branches/master/sta... [2] http://chriswarbo.net/git/chriswarbo-net/branches/master/sta... [3] http://chriswarbo.net/git/chriswarbo-net/branches/master/sta...
http://paquari.com/qsort2000.png
Quicksort of 2000 random elements, (x,y) is black iff the algorithm compares x and y. You can clearly see how the pivots get compared to all the other elements.
http://paquari.com/msortOrig2000.png
A similar picture for merge-sort, but here (x,y) is black iff the algorithm compares the elements at original position x and y.
http://paquari.com/msort2000.png
Mergesort, but colouring like in the Quicksort case.
The points mentioned in the article about streaming data and untrustworthy images make sense, but would be useful even outside the context of a browser rendering engine (e.g. many local image files will have come from the Web, so are just as untrustworthy).
Because a dedicated library could change its API in version 2.0, and at the same time fix important security flaws. At that point your only options are: switch to a different library, write your own library, put the old API back in the original library, or ask the maintainers of the library. All of those options are difficult or unreliable, especially given the small timeframe in which it all should happen.
The correct thing to do is back-port fixes to the 1.x branch, or come up with an alternative fix if the 1.x/2.x transition changes too much (in the latter case, the 1.x and 2.x versions would essentially be different libraries which just-so-happen to share the same name). Anyone can (attempt to) do this patch, including the library authors, the browser authors (who may be the same people), or any other users of the library.
If upstream don't accept such patches, and repeatedly indulge in such uncooperative behaviour, there is always the option to fork (and, in the process, perhaps strip out the parts which the browser doesn't need to make maintenance easier).
As an aside, the situation you describe sounds a lot like the Firefox/Iceweasel drama in Debian!
I think both of our definitions of "correct" coincide.
The reason to use libraries is precisely so that the applications will work, not break each other, be secure, etc.
The article talks about different browsers supporting different sub-sets of possible BMPs; from a user perspective, I wouldn't call that working.
> the culmination of these two leads to 'the browser contains all the libraries it needs'
This doesn't conflict with what I said. Write as many libraries as you like. Grab as many third-party ones as you want. Use OS-provided ones if you prefer that. Bundle them with your browser, I don't care. Statically link the binaries if it makes things easier. Keep copies of the libraries in your browser's source control if you think that's best. I wasn't addressing any of that.
My point was to use libraries; regardless of who writes them, how they're distributed, how they're linked, etc.
> This whole forking crap is exactly the last thing the end user wants or needs to care about.
Erm, exactly? Nobody likes to fork a project. It's a last resort for bad situations. End users certainly do care when devs steer a project off course; hell, just look at the outcry that happens whenever some social media site changes its colour scheme a little!
Meaning you can download said archive, extract it onto some storage media, and run it from there on a compatible platform.
I don't think that's the main benefit of using/developing an external library for this. To me, using an external library sounds like a good idea because:
- You get code separation. A bit less code on the main Firefox repo, and a repo dedicated only to BMP decoding (or image files in general). Someone who wants to contribute to the BMP decoder wouldn't need to download all FF repo and understand/configure its build system. Big plus!
- The library can be shared among different applications. It doesn't make sense for each browser to have a different implementation of BMP decoding, each with their own bugs. Sharing a library for this kind of stuff would actually benefit security, as a bug fixed by one browser/app developer would benefit the others.
That last one is the biggest thing for me. The BMP example is a very simple one, and not very important. It is in more complex tasks that i think sharing libraries would be much more beneficial.
For example, wouldn't it be great that, instead duplicating so much effort in implementing the streaming capabilities of Media Source Extensions [1], the different browsers shared a library dedicated to that complex task? We could have had a more complete and robust implementation in less total time! And that's just one example; there are tons of complex things browsers do that could be extracted to separate shared libraries.
[1]: And so many bugs https://bugzilla.mozilla.org/show_bug.cgi?id=778617
This is incredibly important for security. Reducing complexity and possible attack surface even between components is something that has been ignored in software for far too long.
Crypto shouldn't ever be in the same address space of any process that also does parsing or network I/O. That's just asking for the keys to be leaked (or other problems) when the inevitable bug is found.
1) Just determine some metadata about the image (size and a few other things) but don't decode the pixel data yet.
2) Asynchronously decode the pixel data on a separate thread, notify when done.
3) Synchronously decode the pixel data on the current thread.
4) Asynchronously decode the pixel data on a separate thread, notify as you go. This can have variants along the lines of "Progressive JPEG" as opposed to just delivering more scanlines.
Now ideally a good library would in fact let you do all of this as needed (e.g. Firefox just uses libpng for PNG decoding, though even there it's patched locally to add APNG support). Not all image formats have good libraries.
> On the web it’s mostly used on the web for favicons though it can be used for normal images.
Basically the .ico format often used for favicons comes from Windows icons (the first favicon implementation originated in Internet Explorer and MS supported .ico so people could reuse existing application icon files, though IIRC .gif files and other formats supported in web pages could be used from the start too) which are a variant of the .bmp format which has a few extra features like containing different images for different sizes (so a single file can contain separately optimised 16x16 and 32x32 bitmaps).
I assume .ico and .bmp files are fairly rare now, presumably completely unheard of for new sites/apps, but you can't drop support because there are enough of them out there on legacy sites that it would break things people care about.
I have kept our icons in .ico format but I thought that was to support proper legacy IE (5 and below). Where I have used other formats I presumably didn't notice the icon not working in IE8/9/10 because I generally only care about Firefox & Chrome and worry about IE10/11 breaking when someone reports a problem [if someone reports a problem in IE prior to 10 outside of my day job (where I have to support IE8 for some rather backward clients) I consider that their problem because of their browser choice, and even 10 is rapidly dropping off my care radar].
Many years ago I wrote the code to support PBM/PGM/PPM images for Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=117983). They never got that much traction on the web though, and so support for that image format was dropped: <https://bugzilla.mozilla.org/show_bug.cgi?id=197530>.