Hacker News Reader

Comment by Karellen | Hacker News Reader

> 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?

View on HN

> 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.

> [libc and the kernel] currently have a much better guaranteed quality than systemd,

What are you basing that on?

Historical behavior.

There doesn't exist anything else this could be based on.

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/gnu-c-library-glibc

https://scan.coverity.com/projects/systemd

> 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.

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.

> 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.

> 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.

Reply on news.ycombinator.com