5 ms·

Whether you know it or not, you have used libjpeg-turbo. In fact you are probably using it every day, it's just behind the scenes, just like openssl is. These

by aspyct 3y ago

Whether you know it or not, you have used libjpeg-turbo. In fact you are probably using it every day, it's just behind the scenes, just like openssl is. These projects deserve funding, if at least from giants like facebook & co.

defrost 3y ago
> These projects deserve funding, if at least from giants like facebook & co. Absolutely. Looking at: https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/3.0.0 https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/... one wonders what possible harm could come from leaving image decompression buffer faults from maliciously crafted jpegs in popular browsers and software unattended.
- winter_blue 3y ago
  > one wonders what possible harm could come from leaving image decompression buffer faults from maliciously crafted jpegs in popular browsers and software unattended This is yet another reason a switch to a memory-safe language like unsafe-free Rust is highly imperative.
  - bombolo 3y ago
    I'm sure in a couple of years a new category of security bugs that can happily happen in rust will pop up.
    - mcherm 3y ago
      ...at which point the code written in C will suffer from BOTH categories of bug, while code written in any language whose compiler guarantees memory safety will not. Guaranteeing memory safety isn't just an overhyped benefit meaningful only to Rust fanboys. It is also one important reason why much code is written in Java, Python, or JavaScript. It is a valuable property for any language to have.
      - bombolo 3y ago
        Rust doesn't guarantee memory safety in general… it is better at it than C for sure, but not impossible to have bugs there too. The 100% certainty you use to claim it's absolutely memory safe is the essence of the problem with the rust fanboys.
        winter_blue 3y ago
        I think you might need to define what exactly you mean by "memory safe". There is an entire class of bugs common to C and C++ that absolutely never happen in JVM languages, CLR languages, Rust, etc. This particular class of bugs of bugs never happen by design, because the language design simply does not permit them to occur ever.¹ ¹ I am obviously of course excluding bugs/exploits/unintentional-loopholes here that are in the JVM or CLR, or in the Rust compiler itself, that permit a program to "break out of its box", so to speak.
        bombolo 3y ago
        https://doc.rust-lang.org/book/ch15-06-reference-cycles.html https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
        winter_blue 3y ago
        This is a super-well-known issue with reference counting in general. It would be something to deal with anywhere one uses reference counting exclusively. For example, this is a problem in Swift as well: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/#Strong-Reference-Cycles-Between-Class-Instances https://docs.swift.org/swift-book/documentation/the-swift-pr... Does that mean Swift is unsafe? No. All this does is create the potential for a memory leak. Which is nowhere close to being in the same category as a buffer overflow exploit. Also, I suppose one could write a garbage-collected pointer library for Rust, which adds cycle detection (and auto-deletion) on top of ARC.
  - jeroenhd 3y ago
    While I think the move to safer code through Rust and other alternatives is a nice breath of fresh air, I doubt you can get these kinds of optimization without using unsafe code in Rust. These optimized implementations often require some kind of safety-bypassing memory modifications to work as efficiently ad they do. There's a reason https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/simd/x86_64 https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim... is filled with assembly files with conditional loading.
    - winter_blue 3y ago
      Oh wow, I didn't realize there were mountains of Assembly in there. If this is the case, I'd say: let's put libraries like this Docker-like containers (in their processes with their own address space), and use mmap/etc-based highly-efficient IPC to interact with them. With all the hyper-optimized assembly in there, it's probably still more efficient even with the container penalty (which, tbh, is close to zero on Linux these days).
  - tialaramex 3y ago
    For this work we don't need a general purpose language like Rust. WUFFS is a special purpose language for Wrangling Untrusted File Formats Safely: WUFFS pays a high price (loss of generality) for a valuable reward (compile time assurance of memory safety, very high performance) and it makes no sense for people to hand roll this sort of software in C when they should use WUFFS. https://github.com/google/wuffs https://github.com/google/wuffs
    - winter_blue 3y ago
      Wow, WUFFS is amazing. I wonder if a hypothetical new/future general-purposes language could have a non-Turing-complete subset within it with WUFFS-like guarantees.

by aspyct 3y ago

defrost 3y ago

> These projects deserve funding, if at least from giants like facebook & co. Absolutely. Looking at: https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/3.0.0 https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/... one wonders what possible harm could come from leaving image decompression buffer faults from maliciously crafted jpegs in popular browsers and software unattended.

winter_blue 3y ago
> one wonders what possible harm could come from leaving image decompression buffer faults from maliciously crafted jpegs in popular browsers and software unattended This is yet another reason a switch to a memory-safe language like unsafe-free Rust is highly imperative.
- bombolo 3y ago
  I'm sure in a couple of years a new category of security bugs that can happily happen in rust will pop up.
  - mcherm 3y ago
    ...at which point the code written in C will suffer from BOTH categories of bug, while code written in any language whose compiler guarantees memory safety will not. Guaranteeing memory safety isn't just an overhyped benefit meaningful only to Rust fanboys. It is also one important reason why much code is written in Java, Python, or JavaScript. It is a valuable property for any language to have.
    - bombolo 3y ago
      Rust doesn't guarantee memory safety in general… it is better at it than C for sure, but not impossible to have bugs there too. The 100% certainty you use to claim it's absolutely memory safe is the essence of the problem with the rust fanboys.
      - winter_blue 3y ago
        I think you might need to define what exactly you mean by "memory safe". There is an entire class of bugs common to C and C++ that absolutely never happen in JVM languages, CLR languages, Rust, etc. This particular class of bugs of bugs never happen by design, because the language design simply does not permit them to occur ever.¹ ¹ I am obviously of course excluding bugs/exploits/unintentional-loopholes here that are in the JVM or CLR, or in the Rust compiler itself, that permit a program to "break out of its box", so to speak.
        bombolo 3y ago
        https://doc.rust-lang.org/book/ch15-06-reference-cycles.html https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
        winter_blue 3y ago
        This is a super-well-known issue with reference counting in general. It would be something to deal with anywhere one uses reference counting exclusively. For example, this is a problem in Swift as well: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/#Strong-Reference-Cycles-Between-Class-Instances https://docs.swift.org/swift-book/documentation/the-swift-pr... Does that mean Swift is unsafe? No. All this does is create the potential for a memory leak. Which is nowhere close to being in the same category as a buffer overflow exploit. Also, I suppose one could write a garbage-collected pointer library for Rust, which adds cycle detection (and auto-deletion) on top of ARC.
- jeroenhd 3y ago
  While I think the move to safer code through Rust and other alternatives is a nice breath of fresh air, I doubt you can get these kinds of optimization without using unsafe code in Rust. These optimized implementations often require some kind of safety-bypassing memory modifications to work as efficiently ad they do. There's a reason https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/simd/x86_64 https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim... is filled with assembly files with conditional loading.
  - winter_blue 3y ago
    Oh wow, I didn't realize there were mountains of Assembly in there. If this is the case, I'd say: let's put libraries like this Docker-like containers (in their processes with their own address space), and use mmap/etc-based highly-efficient IPC to interact with them. With all the hyper-optimized assembly in there, it's probably still more efficient even with the container penalty (which, tbh, is close to zero on Linux these days).
- tialaramex 3y ago
  For this work we don't need a general purpose language like Rust. WUFFS is a special purpose language for Wrangling Untrusted File Formats Safely: WUFFS pays a high price (loss of generality) for a valuable reward (compile time assurance of memory safety, very high performance) and it makes no sense for people to hand roll this sort of software in C when they should use WUFFS. https://github.com/google/wuffs https://github.com/google/wuffs
  - winter_blue 3y ago
    Wow, WUFFS is amazing. I wonder if a hypothetical new/future general-purposes language could have a non-Turing-complete subset within it with WUFFS-like guarantees.