blucaz

Joined 3 years ago

Karma

Submissions

Member since

Oct 9

Recent submissions

That model is utter garbage for many reasons, for example every single ROP-style attack now has access to the entire codebase, instead of just what is part of the individual, tiny binary. Another example, it makes it pretty much impossible to restrict access to the discrete binaries via LSMs. And so on, and so forth.

Comment · 9 months ago

"While the above attack did use the systemd vsock sshd listener for Escape to Host, the attacker could have just directly listened over the vsock loopback."

https://www.openwall.com/lists/oss-security/2026/01/08/7

TL;DR: a clueless user fails to understand and configure his own systems, but for clickbait effect chooses to blame the evil SyStEmD!!!11 instead of his own incompetence

Comment · 10 months ago

Maintaining separate upstream sources and downstream patches does provide value. Maybe not to you, but it does.

For example, it's trivial from a web browser with a couple of clicks to go and find out all the downstream changes to a package. For example to see how glibc is currently customized in debian testing/unstable you can just navigate this webpage:

https://sources.debian.org/src/glibc/2.42-6/debian/patches

If everything gets merged in the same git tree it's way harder. Harder but doable with a rebase+force push workflow, which makes collaboration way harder. Just impossible with a merge workflow.

As an upstream maintainer of several project, being able to tell at a glance and with a few clicks how one of my projects is patched in a distribution is immensely useful when bug reports are opened.

In a past job it also literally saved a ton of money because we could show legal how various upstreams were customized by providing the content of a few .debian.tar.gz tarballs with a few small, detached patches that could be analyzed, instead of massive upstream trees that would take orders of magnitude more time to go through.

Comment · 10 months ago

It gracefully falls back if the new option is not available at runtime

Comment · 1 year ago

No, the graphics stack needs to be native and in sync for obvious reasons, and that includes the mesa libraries. What can be in the runtime is already in the runtime.

Comment · 1 year ago

> The reality is that no such documentation is provided, so the only way to avoid systemd is to become an expert in its internals.

The blog post subject of the thread literally links to the documentation. If you can't even be bothered clicking on the provided links, what are you even doing commenting on such a thread. But by all means, don't let facts get in the way of a good baseless rant.

Comment · 1 year ago

It's not even that, that whole story's main point was about how an incredibly complex, sophisticated and lengthy social engineering attack was carried out, probably by a nation-state actor, after singleing out an over-worked open source maintainer of a core project (xz) doing a thankless job and getting pressured left-and-right until he caved (no fault of his own), and they managed to install an updatable, generic backdoor that could be used to attack literally anything. The initial version was chosen to target sshd <-- libsystemd <-- xz.

The takeway that sensible people go away with is that core critical infrastructure needs to be properly funded, and people need to stop harassing open source maintainers.

Idiots instead rant about "muh systemd" and use it to attack other maintainers.

Comment · 1 year ago

> I’m somewhat a fan of systemd and I’m interested in immutable images, but I don’t want to build systemd from source:

You don't have to, we build packages and publish repositories from latest main, and the particle configs can use those by enabling the 'obs' build profile

Comment · 1 year ago

> So how do I replace any of them with my own, small tool?

You write them with an equivalent public interface.

> They have no stable interfaces.

This is nonsense. All the D-Bus (and now Varlink too) interfaces are stable, documented and we do not break backward compatibility.

> yet nobody was able to write a replacement.

That's because actually doing things is hard, but complaining on social media is extremely easy.

Comment · 1 year ago

> The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.

It is not. There are other, very real and very important problems with that fact and reasons why it should be fixed, but this is not it. The point of SecureBoot is to protect the firmware from userspace. It works very well for that purpose, as evidenced by the facts that exploits to bypass it have to continuosly be found.

Comment · 2 years ago

> When configuring boot media, like an SD card, for an embedded ssystem that is not the running system where the configuration is occurring, this is an impediment. There is systemd-firstboot, etc, but this is not as convenient as just being able to set config options on the mounted (non-booted) embeddded media.

systemctl --root /path/to/sd/card/ <...>

Comment · 2 years ago

Debian, Ubuntu and all derivatives thereof use initramfs-tools, which does not use systemd in the initrd, and things work just fine

Comment · 2 years ago

malloc_info() is not consumed internally but it is only wired up as a debugging utility via systemd-analyze, which is sorely needed when things go bad in strange and weird ways. It would be entirely fine for a libc to just implement a stub that returns a fixed string:

<malloc version="0">Not implemented</malloc>

or so.

Comment · 2 years ago

For the record, it turned out this was just a series of misunderstandings on the part of the OP on how configuring networking works on Linux, and the differences between how the kernel and how userspace manage and configure addresses. These points have all been clarified by myself and another maintainer on https://github.com/systemd/systemd/issues/33866

- the assertion is made that networkd creates link local addresses - it does not, the kernel does.

- the assertion is made that configuring how the _kernel_ sets up link local addresses must automatically and silently affect how userspace network managers configure global addresses. This is of course not the case, and one might ask for such a feature, but its absence most definitely does not mean that it is "utterly inadequate for IPv6 or dual-stack installations".

- the assertion is made that userspace network managers independently listening on RA packets and creating SLAAC global addresses independently of the kernel must set the stable-privacy interface flag. This is not the case, such flags are owned by the kernel and cannot be set by userspace. Being absent does not mean the the addresses are not private or stable, it just means they are not kernel managed, and thus a different (RFC 7217 compliant) algorithm is used as explained on https://www.freedesktop.org/software/systemd/man/latest/syst...

- the assertion is made that the suffixes generated by the _kernel_ to set up link local addresses must automatically and silently be copied by userspace network managers to configure global addresses on the respective interfaces. This is also of course not the case, the algorithm is described in the link above, and again asking for such a new feature is fine, but its absence does not mean that it is "utterly inadequate for IPv6 or dual-stack installations".

- the assertion is made that certain defaults must be changed to meet the OP's personal preferences. This of course cannot really be done in a project like systemd, where we try our best to keep backward compatibility, even if we don't always succeed. The desired configuration is very easy to setup, for example this should suffice:

[Network] IPv6PrivacyExtensions=yes IPv6LinkLocalAddressGenerationMode=stable-privacy

[IPv6AcceptRA] Token=prefixstable

As usual, it would be best to ask clarification questions and investigate how things actually work _before_ making definitive assertions on a blog post about a component for which one has a cursory understanding at best, but that's not nearly as much fun as a good ol' systemd bashing blog post, right?

Comment · 2 years ago

> Systemd-boot, any boot loader, that aims to replicate the things that the kernel does is ultimately going to run into the same problems as grub. We're going to have the font CVEs, we're going to have filesystem and storage and memory allocation bugs. All of that stuff is going to exist in whatever boot loader. > Again, for an individual user, if you want to install systemd-boot, great, go ahead and use it. It's good, it works. But as a general option it's just going to have the same issues, unfortunately.

This is completely wrong though - the main point of sd-boot is that it does _not_ implement any of that - no filesystems, no fonts, no themes, nothing at all, the firmware is used to do all the risky stuff via the UEFI protocols. So it is very much not reimplementing what grub or the kernel do, the exact opposite in fact, it's the number one design goal.