4 ms·

> 1a. As a consequence of (1) autogenerated artifacts should always be committed. Why don't object files and binaries count as autogenerated artifacts? Should

> 1a. As a consequence of (1) autogenerated artifacts should always be committed. Why don't object files and binaries count as autogenerated artifacts? Should we commit those to the repo too? Where is the line between an artifact that should be committed, and one that shouldn't be? > 4. Libsystemd is a problem for the ecosystem. libc will dynamically load libnss-* on a lot of platforms, some of which can link to a bunch of other helper libraries. What if the attack had come via one of those 2-or-3-dependencies-removed libraries? libc is big and complicated and most programs only use a tiny fraction of it. Is libc a problem for the ecosystem?

marcosdumay 3y ago
> Is libc a problem for the ecosystem? Absolutely yes. And also the size of the kernel. Those two currently have a much better guaranteed quality than systemd, thus systemd is a much more pressing issue. But they don't stop being a problem just because they are not the largest one.
- Karellen 3y ago
  > [libc and the kernel] currently have a much better guaranteed quality than systemd, What are you basing that on?
  - marcosdumay 3y ago
    Historical behavior. There doesn't exist anything else this could be based on.
    - Karellen 3y ago
      Does systemd have a historical record of its defect rate being significantly greater than that of the kernel/glibc? I just checked Coverity scans, and the most recent defect densities appear to be: kernel : 0.59 glibc : 0.54 systemd: 0.04 which actually looks pretty good for systemd. Is there some other analysis you're basing this off? Or are the current rates atypical, and systemd used to be a lot worse? https://scan.coverity.com/projects/linux https://scan.coverity.com/projects/linux https://scan.coverity.com/projects/gnu-c-library-glibc https://scan.coverity.com/projects/gnu-c-library-glibc https://scan.coverity.com/projects/systemd https://scan.coverity.com/projects/systemd
- dralley 3y ago
  > the size of the kernel Is mostly in the hardware support, only a tiny fraction of which is actually active. Linux has a lot of drivers, many of them are crap, but it's not obvious to me that Linux would be better off with no driver than a crap driver.
  - marcosdumay 3y ago
    That tiny fraction is quite huge. Filesystems and networking support are well known problematic areas, the sound system is a chapter by itself, and Linux is full of old, should-be-unused interfaces that attackers successfully use once in a while. Besides, the core part of the kernel is way too big for anybody to read. And any of it can interact with any other part.
th3typh00n 3y ago
> libc is big and complicated and most programs only use a tiny fraction of it. Is libc a problem for the ecosystem? IMO yes. I definitely believe having basic common functionality (malloc, printf, memcpy etc.) provided by one library with all the crazy/obscure stuff that very few people need or want somewhere else would be an improvement.
EdiX 3y ago
> Why don't object files and binaries count as autogenerated artifacts? Should we commit those to the repo too? Where is the line between an artifact that should be committed, and one that shouldn't be? I'd say anything that is input to the compiler should be. > libc will dynamically load libnss-* on a lot of platforms, some of which can link to a bunch of other helper libraries. What if the attack had come via one of those 2-or-3-dependencies-removed libraries? libc is big and complicated and most programs only use a tiny fraction of it. Is libc a problem for the ecosystem? Yes, the libnss stuff is also a problem.

marcosdumay 3y ago

> Is libc a problem for the ecosystem? Absolutely yes. And also the size of the kernel. Those two currently have a much better guaranteed quality than systemd, thus systemd is a much more pressing issue. But they don't stop being a problem just because they are not the largest one.

Karellen 3y ago
> [libc and the kernel] currently have a much better guaranteed quality than systemd, What are you basing that on?
- marcosdumay 3y ago
  Historical behavior. There doesn't exist anything else this could be based on.
  - Karellen 3y ago
    Does systemd have a historical record of its defect rate being significantly greater than that of the kernel/glibc? I just checked Coverity scans, and the most recent defect densities appear to be: kernel : 0.59 glibc : 0.54 systemd: 0.04 which actually looks pretty good for systemd. Is there some other analysis you're basing this off? Or are the current rates atypical, and systemd used to be a lot worse? https://scan.coverity.com/projects/linux https://scan.coverity.com/projects/linux https://scan.coverity.com/projects/gnu-c-library-glibc https://scan.coverity.com/projects/gnu-c-library-glibc https://scan.coverity.com/projects/systemd https://scan.coverity.com/projects/systemd
dralley 3y ago
> the size of the kernel Is mostly in the hardware support, only a tiny fraction of which is actually active. Linux has a lot of drivers, many of them are crap, but it's not obvious to me that Linux would be better off with no driver than a crap driver.
- marcosdumay 3y ago
  That tiny fraction is quite huge. Filesystems and networking support are well known problematic areas, the sound system is a chapter by itself, and Linux is full of old, should-be-unused interfaces that attackers successfully use once in a while. Besides, the core part of the kernel is way too big for anybody to read. And any of it can interact with any other part.

th3typh00n 3y ago

> libc is big and complicated and most programs only use a tiny fraction of it. Is libc a problem for the ecosystem? IMO yes. I definitely believe having basic common functionality (malloc, printf, memcpy etc.) provided by one library with all the crazy/obscure stuff that very few people need or want somewhere else would be an improvement.

EdiX 3y ago

> Why don't object files and binaries count as autogenerated artifacts? Should we commit those to the repo too? Where is the line between an artifact that should be committed, and one that shouldn't be? I'd say anything that is input to the compiler should be. > libc will dynamically load libnss-* on a lot of platforms, some of which can link to a bunch of other helper libraries. What if the attack had come via one of those 2-or-3-dependencies-removed libraries? libc is big and complicated and most programs only use a tiny fraction of it. Is libc a problem for the ecosystem? Yes, the libnss stuff is also a problem.