systemd
linux
systemd | linux | |
---|---|---|
517 | 981 | |
12,516 | 170,551 | |
1.6% | - | |
10.0 | 10.0 | |
1 day ago | 4 days ago | |
C | C | |
GNU General Public License v3.0 only | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
systemd
-
Run0 – systemd based alternative to sudo announced
> 3. even `adduser` will not allow it by default
5. useradd does allow it (as noted in a comment). 6. Local users are not the only source, there things like LDAP and AD.
7. POSIX allows it:
* https://github.com/systemd/systemd/issues/6237#issuecomment-...
-
Systemd Rolling Out "run0" As sudo Alternative
> I for one love to type out 13 extra characters
FWIW, systemd is normally pretty good at providing autocomplete suggestions, so even if you don't want to set up an alias you'll probably just have to type `--b ` to set it.
> I wonder what random ASCII escape sequences we can send.
According to the man page source[0]:
> The color specified should be an ANSI X3.64 SGR background color, i.e. strings such as `40`, `41`, …, `47`, `48;2;…`, `48;5;…`
and a link to the relevant Wikipedia page[1]. Given systemd's generally decent track record wrt defects and security issues, and the simplicity of valid colour values, I expect there's a fairly robust parameter verifier in there.
In fact, given the focus on starting the elevated command in a highly controlled environment, I'd expect the colour codes to be output to the originating terminal, not forwarded to the secure pty. That way, the only thing malformed escapes can affect is your own process, which you already have full control over anyway.
(Happy to be shown if that's a mistaken expectation though.)
[0] https://github.com/systemd/systemd/blob/main/man/run0.xml
[1] https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_G...
- Crash-only software: More than meets the eye
-
Systemd Wants to Expand to Include a Sudo Replacement
bash & zsh are supported by upstream: https://github.com/systemd/systemd/tree/main/shell-completio...
-
"Run0" as a Sudo Replacement
the right person to replace sudo, not: https://github.com/systemd/systemd/issues/6237
PS: https://pwnies.com/systemd-bugs/
-
Linux fu: getting started with systemd
https://github.com/systemd/systemd/issues/32028#issuecomment...
There are some very compelling arguments made there if you care to read them
-
Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies
Maybe it was because you weren't pointing out anything new?
There was a pull request to stop linking libzma to systemd before the attack even took place
https://github.com/systemd/systemd/pull/31550
This was likely one of many things that pushed the attackers to work faster, and forced them into making mistakes.
-
Systemd minimizing required dependencies for libsystemd
The PR for changing compression libraries to use dlopen() was opened several weeks before the xz-utils backdoor was revealed.
https://github.com/systemd/systemd/pull/31550
- Going in circles without a real-time clock
-
The xz sshd backdoor rabbithole goes quite a bit deeper
I find this the most plausible explanation by far:
* The highly professional outfit simply did not see teknoraver's commit to remove liblzma as standard dependency of systemd build scripts coming.
* The race was on between their compromised code and that commit. They had to win it, with as large a window as possible.
* This caused serious errors.
* The performance regression is __not__ big. It's lucky Andres caught it at all. It's also not necessarily all that simple to remove it. It's not simply a bug in a loop or some such.
* The payload of the 'hack' contains fairly easy ways for the xz hackers to update the payload. They actually used it to remove a real issue where their hackery causes issues with valgrind that might lead to discovering it, and they also used it to release 5.6.1 which rewrites significant chunks; I've as yet not read, nor know of any analysis, as to why they changed so much.
Extra info for those who don't know:
https://github.com/systemd/systemd/commit/3fc72d54132151c131...
That's a commit that changes how liblzma is a dependency of systemd. Not because the author of this commit knew anything was wrong with it. But, pretty much entirely by accident (although removing deps was part of the point of that commit), almost entirely eliminates the value of all those 2 years of hard work.
And that was with the finish line in sight for the xz hackers: On 24 feb 2024, the xz hackers release liblzma 5.6.0 which is the first fully operational compromised version. __12 days later systemd merges a commit that means it won't work__.
So now the race is on. Can they get 5.6.0 integrated into stable releases of major OSes _before_ teknoraver's commit that removes liblzma's status as direct dep of systemd?
I find it plausible that they knew about teknoraver's commit _just before_ Feb 24th 2024 (when liblzma v5.6.0 was released, the first backdoored release), and rushed to release ASAP, before doing the testing you describe. Buoyed by their efforts to add ways to update the payload which they indeed used - March 8th (after teknoraver's commit was accepted) it was used to fix the valgrind issue.
So, no, I don't find this weird, and I don't think the amateurish aspects should be taken as some sort of indication that parts of the outfit were amateuristic. As long as it's plausible that the amateuristic aspects were simply due to time pressure, it sounds like a really bad idea to make assumptions in this regard.
linux
-
The File Filesystem
FFS predates FreeBSD and is in some capacity supported by all 3 major BSDs. I'm fairly confident that Linux actually supports it through the ufs driver ( https://github.com/torvalds/linux/tree/master/fs/ufs ); whether the use of different names in different places makes it better or worse is an exercise for the reader.
-
Linus Torvalds adds arbitrary tabs to kernel code
These are a bit easier to see what's going on:
https://github.com/torvalds/linux/commit/d5cf50dafc9dd5faa1e...
https://github.com/torvalds/linux/blob/d5cf50dafc9dd5faa1e61...
Unfortunately Github doesn't have a way to render symbols for whitespace, but you can tell by selecting the spaces that the previous version had leading tabs. Linus changed it so that the tokens `default` and the number e.g. `12` are also separated by a tab. This is tricky, because the token "default" is seven characters, it will always give this added tab a width of 1 char which makes it always layout the same as if it were a space no matter if you use tab widths of 1, 2, 4, or 8.
- Show HN: Running TempleOS in user space without virtualization
-
PfSense Software Embraces Change: A Strategic Migration to the Linux Kernel
There was also a Gentoo effort to run atop FreeBSD[0]. The challenge of course is that afaik none of the BSD kernel ABIs are considered stable. The stable interface is the BSD libc. That said, with binfmt_misc, I don't see a reason you couldn't just run (at least some) FreeBSD binaries on Linux with a thin syscall translation layer (rather something like qemu-system) and then your layer hooked via binfmt_misc. I'm not aware of anyone who has done this for FreeBSD, but prior efforts existed as alternate binfmts for SysVr4/5 ELF binaries[2]. Either way would take some elbow grease, but you *might* even be able just reuse binfmt_elf and just have a new interpreter for FreeBSD elf.
[0] https://wiki.gentoo.org/wiki/Gentoo_FreeBSD
[1] https://docs.kernel.org/admin-guide/binfmt-misc.html
[2] https://github.com/torvalds/linux/blob/master/fs/binfmt_elf....
-
Improvements to static analysis in GCC 14
> The original less-than check was deemed incorrect
It was only deemed incorrect because of an information leak. Not because it's a valid use-case for user space to copy smaller portions of *hwrpb into user space. https://github.com/torvalds/linux/commit/21c5977a836e399fc71...
- Linus Torvalds accepts a merge commit to the Linux kernel
-
TinyMCE (also) moving from MIT to GPL
Correct. And the combined work needs to carry the MIT license text and copyright attributions for the MIT software authors. With binary distribution it must also be overt, not hidden in some source code drop, but directly accompanying the binary.
Many people who talk about relicensing never credit the MIT developers or distribute the MIT license text. "Because it's GPL now."
I don't think that you believe that, but many developers do.
Some don't see the need for source code scans for Open Source compliance, because the license.txt says GPL, so it's GPL. Prime example is the Linux kernel. There is code under different licenses in there, but people don't even read https://github.com/torvalds/linux/blob/master/COPYING till the end ("In addition, other licenses may also apply.") and conclude it's simply GPL 2 and nothing else.
Also be aware that sublicensing is not the same as relicensing.
-
Linus Torvalds is looking for a more modern GUI editor
> Does he have something against it?
He notoriously hates GNU Emacs, yes.
https://marc.info/?m=122955159617722
https://github.com/torvalds/linux/blob/master/Documentation/...
-
The Linux Kernel Prepares for Rust 1.77 Upgrade
So If we would only count code and not comments, it is only 9489 LoC Rust. Which would be about 0.03% and if we take all lines and not only LoC it would be around 0.05%
[0] https://github.com/XAMPPRocky/tokei
[1] https://github.com/torvalds/linux/commit/b401b621758e46812da...
-
Proposed Windows NT sync driver brings big Wine/Proton performance improvements
AIUI fsync is built on futex_waitv which has been upstreamed. So this has to be more than that.
https://github.com/torvalds/linux/commit/a0eb2da92b715d0c97b...
What are some alternatives?
openrc - The OpenRC init system
zen-kernel - Zen Patched Kernel Sources
tini - A tiny but valid `init` for containers
DS4Windows - Like those other ds4tools, but sexier
inotify-tools - inotify-tools is a C library and a set of command-line programs providing a simple interface to inotify.
winapps - Run Windows apps such as Microsoft Office/Adobe in Linux (Ubuntu/Fedora) and GNOME/KDE as if they were a part of the native OS, including Nautilus integration.
s6 - The s6 supervision suite.
Open and cheap DIY IP-KVM based on Raspberry Pi - Open and inexpensive DIY IP-KVM based on Raspberry Pi
earlyoom - earlyoom - Early OOM Daemon for Linux
serenity - The Serenity Operating System 🐞
supervisor - Supervisor process control system for Unix (supervisord)
DsHidMini - Virtual HID Mini-user-mode-driver for Sony DualShock 3 Controllers