41–50 of 162 posts
It's a shame that SystemD, has this issue. Hopefully, once the fix is made, they can get back to the business of obfuscating the init process.
I know you're joking, but it's a nice way to say what they basically do.
EDIT:
I elaborated here: https://news.ycombinator.com/item?id=13470953
>We would like to see that systemd upstream retrieves CVE's themself for their own bugs, even if its believed that its just a local DoS. So not only they didn't notice this was exploitable, they also seem to think that a local DoS is not enough for a CVE or a public report. Excellent.
Did you know that polkit, the systemd replacement of sudo, uses JavaScript to validate permissions? This was the response: https://lists.freedesktop.org/archives/systemd-devel/2016-De... systemd is a bomb waiting to go off, IMHO.
yeah, awesome, i enjoy this systemD shit show. Linux is so doomed.
You're right. Ever since distros made systemd default, computers all over the world have been catching fire, exploding, shooting jets of lava from their headphone jacks. It's the end times
It is NOT a secure project. It's not even remotely so. The development process is too fast and erratic.
It's a shame that SystemD, has this issue. Hopefully, once the fix is made, they can get back to the business of obfuscating the init process.
Earlier quoted context omitted.
2) maybe. mode_t is unsigned and MODE_INVALID was defined as: #define MODE_INVALID ((mode_t) -1) and the problem was in a check: fd = open(path, O_WRONLY|O_CREAT|O_CLOEXEC|O_NOCTTY, mode > 0 ? mode : 0644); so maybe the author thought MODE_INVALID the other thing is maybe in a safe language you would use an Option/Maybe type here instead of a plain mode_t type.
> maybe safe languages will let you do this explicit cast as well They will let you, but explicit casts are a red flag in code review.
A better type system gives you the option to enforce stricter checks to help you catch mistakes, but the same people with the same procedures would have written this bug in any language.
Hey, I wonder what security problems OpenRC, sysvinit, and bsdinit have had in that time?
Food for thought...
Earlier quoted context omitted.
You're right. Ever since distros made systemd default, computers all over the world have been catching fire, exploding, shooting jets of lava from their headphone jacks. It's the end times
You don't really need jets of lava to have a catastrophe. Also, it doesn't have to happen right away - OpenSSL was neglected for years before heartbleed happened. Also, keep in mind that it only takes one vuln to compromise the system and we're definitely hearing of too many of them throughout the time. It is NOT a secure project. It's not even remotely so. The development process is too fast and erratic.
>We would like to see that systemd upstream retrieves CVE's themself for their own bugs, even if its believed that its just a local DoS. So not only they didn't notice this was exploitable, they also seem to think that a local DoS is not enough for a CVE or a public report. Excellent.
Did you know that polkit, the systemd replacement of sudo, uses JavaScript to validate permissions? This was the response: https://lists.freedesktop.org/archives/systemd-devel/2016-De... systemd is a bomb waiting to go off, IMHO.
I honestly do not understand how you can feel comfortable making judgement calls about projects when you cannot even accurately state their function.
Earlier quoted context omitted.
You don't really need jets of lava to have a catastrophe. Also, it doesn't have to happen right away - OpenSSL was neglected for years before heartbleed happened. Also, keep in mind that it only takes one vuln to compromise the system and we're definitely hearing of too many of them throughout the time. It is NOT a secure project. It's not even remotely so. The development process is too fast and erratic.
Yes, tell us all you know about the systemd development process. And while you're at it, enlighten us all about how the it is "too fast"; average citizens like myself see but a pace far slower than those other "NOT secure projects" Chromium, Linux and Postgres.