Hacker News Reader

Comment by jeffbee | Hacker News Reader

FreeType is an endless shitshow of security vulnerabilities going back 25 years now. There's really no excuse in 2020 for writing libraries to decode file formats in unsafe languages. Yes, there are performance-sensitive aspects to image decoding, but opening the file and reading two integers is not one of those.

View on HN

As if this was available 25 years ago. IMHO the real issue is embedded pngs in _fonts_, but YMMV.

Feel free to start rewriting libpng and freetype in rust. See you in 25 years?

It's incorrect to believe that C was the right choice even in 1996. At that time it was already obviously the wrong choice.

It was the only choice that met the performance constraints at the time.

And the common sense at the time did not put too much focus on memory safety.

I was meeting the performance constraints of doing software in MS-DOS with Turbo Pascal.

I wasn't; back then there were a LOT of things, especially in graphics and linear algebra, that required dropping to embedded ASM to accomplish in a performant way. I think Turbo- and Object Pascal were great languages, but let's not pretend they were anywhere near the speed of C.

The point of my remark here is we aren't talking about rendering text along a path or whatever. We're talking about opening a file and parsing a binary format, which is in most use cases not at all performance-sensitive.

C machine code quality was just as slow as anything else on 16 bit computers, lets not pretend otherwise.

Modula-2 and Pascal compilers had the necessary switches to make the languages just as unsafe as C, and anything related to ultimate performance out of 8086 and 68000 required Assembly anyway.

FreeType was initially written in Pascal.

What would you have written freetype in?

Modula-2, Object Pascal.

System programming languages with bounds checking enabled go back to 1961.

We are stuck with C due to the synergy effects of having a free beer OS with source code available.

> IMHO the real issue is embedded pngs in _fonts_, but YMMV.

Png is a pretty simple format that everyone already implements. Would you rather use something ad-hoc?

Looks like this work is already well under way, maybe even already done: https://docs.rs/png/0.16.7/png/ and https://docs.rs/ttf-parser/0.8.2/ttf_parser/ .

I would bet that most libraries chrome uses for file format parsing would not lose any performance at all if rewritten in rust.

You don't even have to drop the remaining zero-days if you apply enough performance hacks using unsafe.

I believe your comment under appreciated the utility of having all unsafe functionality clearly marked as such, with the additional scrutiny that such a label would bring. Instead of having to look through the entire codebase for memory issues, only small set of areas would need to be validated.

The problem is you’d have to rewrite them.

It was not originally meant to be fed malicious inputs from the web all day though. I think the majority of the responsibility rests on people plugging it into web browsers.

I don't think that's really true. Downloading and installing fonts was one of the very first popular activities online. At the time FreeType was written it was easily seen that untrusted inputs would be the norm.

Sure but you can hardly place the same onus of security rigor on the shoulders of a 90's OS/2 software hobbyist enabling people to explicitly download font files once in a blue moon from sources they explicitly choose, vs a big corporation in the 00's employing world class product security staff deciding to stick that in their source tree without even a shrug, where the downloading and applying the fonts happens behind the users back with 0 interaction.

I believe WebKit integrated FreeType2 years before Chrome project even started.

Why do you call it like that? I mean, does it compare bad enough to other font libraries that you feel justified in summarizing it as "an endless shitshow"?

Reply on news.ycombinator.com