3 ms·

And some people say string handling in C is easy. Maybe using memory unsafe languages for anything security related isn't such a good idea after all…

stonogo 3y ago
Feel free to replace libc with a memory-safe implementation.
- jeffbee 3y ago
  That dismissive attitude gives the free software community its bad and well-deserved reputation. There are reasons why some of glibc is written in C or assembly, but 99% of it is just untested neckbeard bullshit that is easily replaced by something safer. There is no legitimate reason why glibc parses environment variables this way.
  - tpush 3y ago
    > [...] its bad and well-deserved reputation. I contest that reputation exists in anything but your own mind or bubble.
  - secondcoming 3y ago
    easily done by _someone else_, I assume?
    - trealira 3y ago
      The fact that they haven't rewritten glibc's string parsing wouldn't make their criticism wrong. If all of glibc had been written in assembly for every single target triplet, one wouldn't be wrong to point out that there was no benefit to doing that instead of writing it in C, and that it probably took more work and was more error-prone, even if they weren't willing to help port said code to C. Just the same, they could have written this in C++. Much of LLVM's libc is written in C++ with exposed C bindings (or all, I haven't checked 100%). For example, their libc stdio implementation is completely in C++. https://github.com/llvm/llvm-project/tree/main/libc/src/stdio https://github.com/llvm/llvm-project/tree/main/libc/src/stdi... You could say the same thing about Rust and Relibc, but it seems much less likely that a C project would incorporate Rust than that it would incorporate C++.
- saagarjha 3y ago
  libc would be a pretty good place to drop a memory-safe replacement, honestly.
  - frankjr 3y ago
    Have a look at Eyra (or more specifically c-ward). https://github.com/sunfishcode/eyra/ https://github.com/sunfishcode/eyra/ https://github.com/sunfishcode/c-ward https://github.com/sunfishcode/c-ward
- skitter 3y ago
  The vulnerable piece of code didn't need memory unsafety. Sure, __minimal_malloc does, but the bug was in mundane string handling.
- rurban 3y ago
  This would need a memory-safe POSIX, which does not exist. Not even proper strings.

stonogo 3y ago

Feel free to replace libc with a memory-safe implementation.

jeffbee 3y ago
That dismissive attitude gives the free software community its bad and well-deserved reputation. There are reasons why some of glibc is written in C or assembly, but 99% of it is just untested neckbeard bullshit that is easily replaced by something safer. There is no legitimate reason why glibc parses environment variables this way.
- tpush 3y ago
  > [...] its bad and well-deserved reputation. I contest that reputation exists in anything but your own mind or bubble.
- secondcoming 3y ago
  easily done by _someone else_, I assume?
  - trealira 3y ago
    The fact that they haven't rewritten glibc's string parsing wouldn't make their criticism wrong. If all of glibc had been written in assembly for every single target triplet, one wouldn't be wrong to point out that there was no benefit to doing that instead of writing it in C, and that it probably took more work and was more error-prone, even if they weren't willing to help port said code to C. Just the same, they could have written this in C++. Much of LLVM's libc is written in C++ with exposed C bindings (or all, I haven't checked 100%). For example, their libc stdio implementation is completely in C++. https://github.com/llvm/llvm-project/tree/main/libc/src/stdio https://github.com/llvm/llvm-project/tree/main/libc/src/stdi... You could say the same thing about Rust and Relibc, but it seems much less likely that a C project would incorporate Rust than that it would incorporate C++.
saagarjha 3y ago
libc would be a pretty good place to drop a memory-safe replacement, honestly.
- frankjr 3y ago
  Have a look at Eyra (or more specifically c-ward). https://github.com/sunfishcode/eyra/ https://github.com/sunfishcode/eyra/ https://github.com/sunfishcode/c-ward https://github.com/sunfishcode/c-ward
skitter 3y ago
The vulnerable piece of code didn't need memory unsafety. Sure, __minimal_malloc does, but the bug was in mundane string handling.
rurban 3y ago
This would need a memory-safe POSIX, which does not exist. Not even proper strings.