Bug#727708: systemd (security) bugs
On Mon, 2013-12-02 at 15:32 -0800, Don Armstrong wrote:
> On Tue, 03 Dec 2013, Josselin Mouette wrote:
> > Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit :
> > > Josselin Mouette <joss@debian.org> writes:
> > >
> > > > There are two implied assumptions here:
> > > > * that the same people are developing all components;
> > > > * that develolpers have the same attention to code quality and
> > > > security in all components they work on.
> > > >
> > > > I don’t think either of them applies to systemd.
> > >
> > > Right, this succinctly captures one of my biggest concerns about systemd.
> >
> > Could you please elaborate on this concern? Is it about the large number
> > of developers, or about the fact they treat important pieces of code
> > more carefully?
>
> Projects which have multiple components, each of which has different
> security/interface surfaces without stable defined interfaces, can lead
> to problems when one set of developers doesn't understand the security
> implications of the parts that they do not work on.
>
> The combination of components into a single monolith is sometimes
> necessary, but it's not clear that it is so in the case of systemd.
IMO "single monolith" is bad terminology - to me that sounds something
like everything in a single process, while the systemd components are
quite modular.
"Not clear it's necessary" seems like an overly negative attitude. There
doesn't seem to be much disagreement about the fact that many of the
systemd components are very useful and would be used even with a
different init. The above security considerations seem purely
theoretical, with no sign that they'd be an issue with systemd in
practice. And IIRC no other actual technical problems resulting from
developing the components together have been brought up in this thread
either. So why should it be done any differently, when this way appears
highly successful?
Reply to: