alt Hacker NewsIsn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack surface?
I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation.
I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we've had since forever.
Replies
This is some strange misinformation.
The C++ JPEG XL decoder is ~30'000 lines, i.e., 3000x smaller than you claim. A non-multithreaded, non-simdified code would be much simpler, around 8000 to 10000 lines of code.
It is not difficult to measure from the repository. The compiled compressed binary for an APK is 5x smaller than that of full AVIF. The complete specification at under 100 pages is ~13x more compact than that of full AVIF.
You mean 100K+? A large chunk of which they say is testing code?
-> They were concerned about the increased attack surface resulting from including the current 100K+ lines C++ libjxl reference decoder, even though most of those lines are testing code.
Seems like Google has created a memory-safe decoder for it in Rust or something.
Google is one of the parties involved in the creating of jxl. If it's their own fault they didn't write a decoder in a memory safe language sooner.
libjxl is is <112,888 lines of code, about 3 orders of magnitude less than you're 100M+ claim.
because memory safety is the only attack vector, as we all know
> ...but now in le Rust!!1
I look forward to the next generation of rubes rewriting this all in some newer ""safe"" language in three decades.
> I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation.
It would need to be written in the Safe Rust subset to give safety assurances. It's an important distinction.
100M+ is a bit more than i would expect for an image format. have i not been paying attention