7 ms·

Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, be

Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen.

jsheard 10mo ago
That's why both Mozilla and Google have predicated their JXL support on a memory-safe implementation. There's a Rust one in the works. I think Google are aiming to replace all of Chromiums decoders with memory-safe ones anyway, even for relatively simple formats.
- philistine 10mo ago
  If that's their plan, I predict another situation exactly like this one where Google decides that removing support is the best move forward. Careful, BMP, Chrome is out to get you!
  - nine_k 10mo ago
    BMP decoding may seem easy and fun (I wrote a toy decoder back in the day), but the vulnerabilities are real: https://nvd.nist.gov/vuln/detail/CVE-2025-32468 https://nvd.nist.gov/vuln/detail/CVE-2025-32468 It's not the format, it's the C / C++ unfortunate baggage.
  - mdriley 10mo ago
    Happy to report the BMP work is actually being done by our friends on the Edge team at Microsoft! https://chromium-review.googlesource.com/c/chromium/src/+/7208236 https://chromium-review.googlesource.com/c/chromium/src/+/72...
    - foresterre 10mo ago
      This actually seems to use the encoder/decoder from the Rust image crate (1), which would bring the opportunity for more memory safe formats once BMP would be accepted. (1) https://crates.io/crates/image https://crates.io/crates/image
chimeracoder 10mo ago
> Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen. At this point, in 2025, any substantial (non-degenerative) image processing written in C++ is a security issue waiting to happen. That's not specific to JPEG XL.
- izacus 10mo ago
  And yet whole of HN is VERY VERY angry because Google won't ship that pile of C++ into most popular software (and app framework) in the world.
  - usrnm 10mo ago
    The most popular software in question is also a giant pile of C++, btw.
    - izacus 10mo ago
      What are you saying here?
      - Lammy 10mo ago
        https://chromium.googlesource.com/chromium/src/+/refs/heads/main https://chromium.googlesource.com/chromium/src/+/refs/heads/...
        izacus 10mo ago
        Communicate. What are you trying to say with these links and insinuations?
    - ncruces 10mo ago
      Are you familiar with the rule of two? https://chromium.googlesource.com/chromium/src/+/main/docs/security/rule-of-2.md https://chromium.googlesource.com/chromium/src/+/main/docs/s... No new code goes in that violates the rule, and ideally no code at all goes in that is both unsafe and parses untrusted data (regardless of sandboxing) and old code doing both gets replaced. A giant pile of C++ can be used for rendering, not parsing untrusted data. A giant pile of C++ can sit behind a validator: a memory-safe JSON validator can vet a stream, before an C++ library deserializes it. Etc.

jsheard 10mo ago

That's why both Mozilla and Google have predicated their JXL support on a memory-safe implementation. There's a Rust one in the works. I think Google are aiming to replace all of Chromiums decoders with memory-safe ones anyway, even for relatively simple formats.

philistine 10mo ago
If that's their plan, I predict another situation exactly like this one where Google decides that removing support is the best move forward. Careful, BMP, Chrome is out to get you!
- nine_k 10mo ago
  BMP decoding may seem easy and fun (I wrote a toy decoder back in the day), but the vulnerabilities are real: https://nvd.nist.gov/vuln/detail/CVE-2025-32468 https://nvd.nist.gov/vuln/detail/CVE-2025-32468 It's not the format, it's the C / C++ unfortunate baggage.
- mdriley 10mo ago
  Happy to report the BMP work is actually being done by our friends on the Edge team at Microsoft! https://chromium-review.googlesource.com/c/chromium/src/+/7208236 https://chromium-review.googlesource.com/c/chromium/src/+/72...
  - foresterre 10mo ago
    This actually seems to use the encoder/decoder from the Rust image crate (1), which would bring the opportunity for more memory safe formats once BMP would be accepted. (1) https://crates.io/crates/image https://crates.io/crates/image

chimeracoder 10mo ago

> Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen. At this point, in 2025, any substantial (non-degenerative) image processing written in C++ is a security issue waiting to happen. That's not specific to JPEG XL.

izacus 10mo ago
And yet whole of HN is VERY VERY angry because Google won't ship that pile of C++ into most popular software (and app framework) in the world.
- usrnm 10mo ago
  The most popular software in question is also a giant pile of C++, btw.
  - izacus 10mo ago
    What are you saying here?
    - Lammy 10mo ago
      https://chromium.googlesource.com/chromium/src/+/refs/heads/main https://chromium.googlesource.com/chromium/src/+/refs/heads/...
      - izacus 10mo ago
        Communicate. What are you trying to say with these links and insinuations?
  - ncruces 10mo ago
    Are you familiar with the rule of two? https://chromium.googlesource.com/chromium/src/+/main/docs/security/rule-of-2.md https://chromium.googlesource.com/chromium/src/+/main/docs/s... No new code goes in that violates the rule, and ideally no code at all goes in that is both unsafe and parses untrusted data (regardless of sandboxing) and old code doing both gets replaced. A giant pile of C++ can be used for rendering, not parsing untrusted data. A giant pile of C++ can sit behind a validator: a memory-safe JSON validator can vet a stream, before an C++ library deserializes it. Etc.