for a full-feature build, down 5 libs which are now dlopened on demand. Last one, libcap, will need to be swapped for some ioctls which won't happen for this release.
I'm trying to have a Target get disabled by a Condition, and then not pull in its dependencies, but the systemd documentation says it's not possible - but doesn't suggest an alternative
A lazy (and free!) Saturday, time to play around and experiment. How about #akonadi managed by #systemd ? #KDE
(Don't worry, I'm not merging this (for now 😈). I'm not even sure if it's a good or a bad idea. And even if it gets merged, it will be optional. I rewrote the process management code to make it extensible, so in the future we can also run Akonadi as a Windows Service or whatever is native on MacOS, with fallback to the mechanism we use today)
The abusive behavior that was being used to manipulate Lasse Collin into bringing on more maintainers for #xz went unnoticed because abusive behavior in Open Source communities is so pervasive. In context, we can clearly see it was part of an orchestrated operation. Out of context, it looks like just another asshole complaining about stuff they have no right to complain about. https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/
@swelljoe
Lol. I wrote this even before knowing that this vuln was caused by a kludge to make SSHD work with #systemd authentication and targets that.
I'm sure the sysemd maintainers have a great corporate excuse for why it's not any of their fault.
There's a huge backdoor (#CVE -2024-3094) allowing remote SSH access (as far as I can tell at this moment) caused by a util called #xz affecting a ton of systems (#Linux and #macOS, well not really) and it's causing quite a huge panic. I honestly don't know much about it just yet, but just sharing some pieces to read about the huge vulnerability.
The person who had maliciously planted this vulnerability into xz-utils, Jia Tan, has made at least 750 contributions to the project over the past 2 years. They even have direct push access to the code repo, allowing them to have pushed commits with forged authors. Being "free" from this vulnerability is not as simple as reverting to a previous version due to just how much and how long they've contributed to the project, and people are rightfully suspicious that this person might have hidden other backdoors in xz.
Unlike most other vulnerabilities, it's a lot harder to pinpoint versions affected by this but the most likely case is most systems out there have xz installed on their system that are impacted - which at this moment, the info being thrown around is any version past 5.3.1, 5.4.6, or 5.6.0 (latest is 5.6.1).
As far as I can tell, you're only impacted by this vulnerability only if:
Your distro sources/packages xz from their release tarballs rather than through the Git source directly.
The payload was only included for the #RPM or #DEB packaging, so unless your distro uses these - you're probably safe.
As far as I can tell, it also only affects x86 systems so #ARM based systems should be fine.
As far as I can tell, your system needs to be running #systemd to be impacted by this, so #Docker/#Podman#containers should mostly if not entirely be fine....? maybe.
In other news, people are currently investigating and evaluating other projects also actively contributed by the compromised developer, Jia Tan, including #libarchive.
People are also analysing the dev's commit history to deduce their background from their activity lol. They've been found to push commits during office hours Mon-Fri, every other Saturdays, presumably Public Holidays that seem to align with China's PH, and seems to be on GMT +8 locale.
I love how Go and Rust programs just compile down to a single binary you can do whatever you want with. Sprinkle a systemd definition and voila, you’ve got yourself a long running service with superpowers 🥰.