|0:00 / 0:00|
|Loading pictures: 0%.
Click here to start before everything is fully loaded.
A letter by Andrew Kanaber to Ian Jackson, listing security bugs in systemd.
Here's the email about systemd security holes that I kept forgetting to send
you. I hope it's (still) useful.
Here's a short summary along with the redhat bug numbers (since the redhat BTS
seems to be the place to go for systemd information)
|txt||CVE summary Debian BTS Redhat|
2012-0871 systemd-logind insecure file creation ? 795853
2012-1101 DoS from systemctl status 662029 799902
2012-1174 TOCTOU deletion race in systemd-logind 664364 803358
2013-4327 insecure use of polkit 723713 1006680
2013-4391 systemd journald integer overflow 725357 859051
2013-4392 TOCTOU race updating file perms 725357 859060
2013-4393 systemd journald DoS 725357 859104
2013-4394 improper sanitization of XKB layouts 725357 862324
A letter by Jef Spaleta to Josselin Mouette, listing Upstart security bugs not marked as such.
So looking deeper into the upstart bug tracker..... I just don't think people have bothered filing CVE requests against upstart at all..ever...for anything..even though there have clearly been some SERIOUS system security impacting bugs that have reached users in Ubuntu releases.
|txt||Here's an example of a file descriptor leak. Canonical did an internal review...didn't request a cve or external impact accessment..and decided it was a normal bug fix. The severity of this is basically the same level of the journald related CVE-2013-4393.|
Here is an example of a simple programming mistake that lead to a user space upstart job causing the pid 1 process to fall over and die. Fixed in an update... no CVE requested. This is pretty severe.
|txt||Here's an example of a FULL ROOT ACCESS exploit from console. Fixed release in Ubuntu with an update... no CVE.|
If had a dog in the debian fight, I'd be very very tempted to call the lack of CVEs on these past security issues bad faith...as if Canonical was trying to purposely avoid calling attention to the severity of these problems.
A letter from Lennart Poettering on the documentation of systemd.
|txt||Our general approach there is that comments shouldn't drown code. Hence: comments for everything that cannot be obviously read from the sources, but not comments for everything we ever write. For example, if you have a function that is called let's say "unit_load()" then this is already indicative enough of what the thing does (loads a unit), that we explicitly do not put a comment there.|
|txt||Note that our public APIs are documented in man pages, and those are not placed in the code. You could probably make our statistics look better in the eyes of the the-more-comments-the-better fraction if we'd not build those man pages from docbook but rather from inline source code comments. (I'd even be willing to do that, but I know of no tool that would allow embedding docbook man XML in C files)|
Anyway, no doubt Upstart has more comments. And no doubt we probably could add mor to our sources. But ultimately this doesn't affect our contributor base too much. It's a matter of taste.
The chairman of the Debian Technical Committee, as well as the representative on the board of directors of the Linux Foundation. As chairman, his vote counts as two in case there is a tie. Also has something to do with amateur radios.
Member of the Debian Technical Committee. A system administrator and software developer in the Debian project, employed by Stanford University.
A Debian developer, member of Ubuntu, and maintainer of Fluxbox.
The leader of the GNOME maintainers for Debian.
Member of the Debian Technical Committee, former Debian Project Leader. Creator of dpkg. Formerly employed by Canonical, currently by Citrix.
Member of the Debian Technical Committee. Maintainer of Upstart and Pluggable Authentication Modules. The release manager for both Debian and Ubuntu.
Member of the Debian Technical Committee. Maintainer of dpkg and GRUB. Has a long time history of working with Canonical, involved with Upstart development.
Member of the Debian Technical Committee. Release manager of Debian. Maintains the Debian policy and getty.
The collective voice of less-important people commenting about the case from the sidelines.
Member of the Debian Technical Committee. Maintainer of Perl-related tools on Debian.