On Mon, Feb 23, 2015 at 12:52 AM, Zbigniew Jędrzejewski-Szmek <[email protected]> wrote: > On Sun, Feb 22, 2015 at 11:58:25PM +0000, Luke Kenneth Casson Leighton wrote:
>> ...except that its introduction (usually --with-libsystemd) in those >> 100 (or so) packages has been done in a mutually-exclusive, >> hard-compile-time switch that *excludes* the possibility of dynamic >> (runtime) decision-making. > I think this is the crux of the matter. Please accept the fact that > this compile time switch does not preclude runtime decision making at > all. When not running under systemd, calls into libsystemd degrade > into silent noops. So they only "cost" that is an extra unused 600kb > library, which is completely insignificant. the problem, zbigniew, is that the intended use of this "silent noop" feature - to make it *possible* to have an alternative PID1 - *hasn't happened*. any upstream software developer who has added in support for systemd has done so by *ripping out* the former alternative code. not a single upstream system that i've seen has done *any* kind of run-time detection *at all*. it's all compile-time. aside from getting the message across to upstream developers about doing runtime detection, i feel that what you guys really need to do is to set up conferences with everyone, to talk - urgently - about ways to ensure that the alternative systems which the wholesale adoption of systemd has excluded may be reinstated as *runtime* choices (not compile-time). that may mean discussing a set of APIs that end up being DL'd (like PAM is, right now), it may mean doing something similar to apache loadable modules, or something like the infrastructure behind python objects, i don't know, but you *need to talk*. and you know what? if you were to say, "we're genuinely concerned that the alternatives to systemd are being locked out, let's talk, urgently. we really mean it", i think you'd find that people would respond positively. the situation now is one where people believe that systemd is being heavily promoted to the exclusion of all other PID1 alternatives, developed with a focus on fedora / redhat to the exclusion of all other distros, developed for desktop systems *only* to the exclusion of servers and embedded systems... it's no wonder that there's a lot of upset people in the software libre community! i know it sounds weird to go backwards, but the situation is - amongst other not very nice things - that the GNU/Linux world now has a new monoculture attack vector at the PID1 level.... in code that's being *actively developed and extended, dramatically*. it was bad enough that shellshock meant that sysvinit was vulnerable right across the board of every GNU/Linux distribution. but at least sysvinit is old enough to have had significant security audit and review over the decades, such that when shellshock was fixed, that was it, problem solved [until the next vulnerability...] contrast that to the situation now: with systemd being so actively developed and then deployed across literally every major GNU/Linux distro without exception, the possibility for serious vulnerabilities having a disproportionately large adverse effect is much higher than i feel it should be. l. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
