Hi Ian,

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
at all”.

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.

Best regards,

To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/x6iova9mt0....@midna.lan

Reply via email to