Ian Jackson ijack...@chiark.greenend.org.uk writes:
My point was that someone who is writing an init system for concurrent
startup and dynamic service management needs to have a good
understanding of concurrent system design, and in particular of race
hazards. I wouldn't expect a person or people who had such an
understanding to make many mistakes of the kind seen here.
Neither do I, but there is no evidence for _many_ of these problems.
Personally, I don’t know about every little detail in fd passing
either. If I read you correctly, you seem to be saying one needs to be
an expert in a given area before being allowed to write code in it. I
think it works the other way around: by writing code in that area, you
become an expert in it.
What a startling statement. This is not some desktop toy we are
talking about; this is critical core system infrastructure.
I would prefer my pid 1 to have been written by experts. It appears
that you are saying that systemd wasn't and that this isn't important!
To clarify: I do think (most?) systemd authors are experts. I am also
saying that experts can make mistakes, and that having the expectation
that software has 0 bugs is unreasonable.
I also stand by my statement that one cannot be an expert in a subject
area before having experience in that subject area. Sure, one can
prepare, but there is the proverb “practice makes perfect”.
Instead of focusing on the actual security issues, what I’d much rather
look at is the process with which such bugs are fixed. I.e. are security
problems acknowledged as such, are they fixed clearly and in a timely
manner? Are there enough eyes looking at the project to uncover, report
and collaborate in fixing the issues?
I don't think having a functioning security response process is a
substitute for good system design, and a high initial code quality.
No argument there. I think having all three of them is better, and
that’s my opinion of systemd, at least of pid 1, which I have looked at
more closely than at the other parts of the larger system.
Also, and I think that should go without saying, if this branch of the
discussion is considered as reasoning against systemd in the decision
process, I’d like to see similar data on the other init systems :).
You are of course welcome to go and find that information.
I may be misunderstanding how this works, but I strongly believe that if
the ctte looks at the security track record of systemd, it MUST also
look at the security track record of the other contenders. I.e., I
consider it unfair to say “we’re not using systemd because it had
security bugs, we’ll chose X instead, but we didn’t look at its security
That said, I’d love to help, but I don’t have the time to look at the
security track record of other init systems in detail. Sorry.
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org