
I rewrote Firefox's BMP decoder - nnethercote
https://blog.mozilla.org/nnethercote/2015/11/06/i-rewrote-firefoxs-bmp-decoder/
======
heinrich5991
I kind of hoped that this would be written in Rust. :)

~~~
nnethercote
There's still a bunch of build system issues to be solved before any Rust code
can be included in Firefox. You can follow along at
[https://bugzilla.mozilla.org/show_bug.cgi?id=1135640](https://bugzilla.mozilla.org/show_bug.cgi?id=1135640).

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...](https://github.com/PistonDevelopers/image/tree/master/src/bmp)
for the code.

~~~
pcwalton
> There's still a bunch of build system issues to be solved before any Rust
> code can be included in Firefox. You can follow along at
> [https://bugzilla.mozilla.org/show_bug.cgi?id=1135640](https://bugzilla.mozilla.org/show_bug.cgi?id=1135640).

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.

~~~
nnethercote
I think Rust is great and I think having Rust code in Firefox will be great.

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!

~~~
pcwalton
I agree with you on the probable time frame here.

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.)

------
raverbashing
BMP was one of the last formats that would be possible to "decode manually"
(that is, read the actual data and paint the image from it). PCX was one of
the other (using RLE)

Sure, easier to use a library, but sometimes you have some constraints

~~~
mnw21cam
Ever heard of the Netpbm image format?

[https://en.wikipedia.org/wiki/Netpbm_format](https://en.wikipedia.org/wiki/Netpbm_format)

~~~
raverbashing
Yes, but they're not very commonplace in 'real usages'

~~~
dr_zoidberg
It depends. A friend of mine works with PAM[1] with satellite images. That
counts as real enough for me.

[1]
[https://en.wikipedia.org/wiki/Netpbm#PAM_graphics_format](https://en.wikipedia.org/wiki/Netpbm#PAM_graphics_format)

------
885895
Interesting write-up. Still, why even support BMP?

~~~
chriswarbo
I think a more pertinent question would be: why have the browser decoding
images at all, rather than loading a dedicated library?

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).

~~~
rwmj
I remember when Mosaic used to launch an external program like 'xv' to display
images. However in answer to your question, it's not clear that having a
library would add any security, since libraries run in the same context as the
rest of the browser (especially on Firefox where the default is still to have
everything running in a single process). You could have an external program to
do rendering, but embedding the output of external programs into the rest of
the output is very inflexible, hard to do, and (with the design of X) not
actually any more secure.

~~~
epidemian
> it's not clear that having a library would add any security

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](https://bugzilla.mozilla.org/show_bug.cgi?id=778617)

~~~
pdkl95
> code separation

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.

------
fazkan
How much of the mozillas code is written in C/C++, and for what purpose...

