64bit time transition.
Now is not a particularly good time to volunteer your main rig as a testing/unstable guinea pig, at least not if you want to get anything (besides being a guinea pig) done.

sshd in daedalus depends on libsystemd0, which may be satisfied by either the real libsystemd0 or by libelogind0 and libelogind-compat.
The former results in sshd being indirectly linked against liblzma as it is in Debian (though I'm not sure if that alone is enough to allow the exploit), the latter does not...

So effectively, both comments are correct depending on the exact set of packages you have installed. Devuan does pull sshd from Debian, so it does link against libsystemd. However the stripped-down copy of that library provided by elogind doesn't load liblzma, because its systemd-notify functionality is a stub.

In any case this is largely academic, as daedalus never shipped the compromised xz versions.

More accurately, targeting sshd (so far, anyway) via a vulnerable understaffed/funded project which just happens to provide attack surface because certain distros patched a security-critical package to add gratuitous linkage to systemd.

This is not about diversity, or even systemd specifically. It's about dependency bloat.

There is zero reason sshd needs to link against anything in systemd, let alone pull in liblzma just to support systemd-notify (and linking a full blown compression lib just to say "sshd is up" to systemd is another level of insane to begin with). Doing this kind of thing opens it up not only to vulnerabilities in such direct dependencies, but also the 9000 other frivolous things those in turn link to.

This is a perfect example of why anyone serious about security resists bloat and feature-creep. Without the ridiculous "because it's there" attitude of the distros involved (particularly WRT systemd integration), this exploit would not have been possible.
If sshd really needed systemd-notify support (and it doesn't), it should have been via a minimal implementation in sshd itself, not pulling in a bunch of bloat and a compression library essentially maintained by one dude.
Distros patching this kind of stuff in downstream is, frankly, pretty irresponsible.

For a quick illumination of just how out of hand this is getting in Debian/Devuan...

$ cat /etc/os-release; ldd /usr/sbin/sshd 
PRETTY_NAME="Devuan GNU/Linux 5 (daedalus)"
NAME="Devuan GNU/Linux"
VERSION_ID="5"
VERSION="5 (daedalus)"
VERSION_CODENAME="daedalus"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"
        linux-vdso.so.1 (0x00007ffc96fde000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f27a6768000)
        libwrap.so.0 => /usr/lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f27a675c000)
        libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f27a672b000)
        libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f27a6719000)
        libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f27a6649000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f27a6619000)
        libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f27a65c7000)
        libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f27a64ed000)
        libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f27a64e7000)
        libcrypto.so.3 => /usr/lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f27a6000000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f27a64c8000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f27a5e1f000)
        libnsl.so.2 => /usr/lib/x86_64-linux-gnu/libnsl.so.2 (0x00007f27a64ab000)
        libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007f27a64a3000)
        libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f27a6497000)
        libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f27a5cd8000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f27a5ca9000)
        libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f27a5bed000)
        liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f27a5bc7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f27a68ec000)
        libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f27a5b2d000)
        libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f27a5b00000)
        libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f27a6487000)
        libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f27a5af9000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f27a5ae8000)
        libtirpc.so.3 => /lib/x86_64-linux-gnu/libtirpc.so.3 (0x00007f27a5aba000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f27a5a92000)

$ cat /etc/os-release; ldd /usr/sbin/sshd 
NAME=Gentoo
ID=gentoo
PRETTY_NAME="Gentoo Linux"
ANSI_COLOR="1;32"
HOME_URL="https://www.gentoo.org/"
SUPPORT_URL="https://www.gentoo.org/support/"
BUG_REPORT_URL="https://bugs.gentoo.org/"
VERSION_ID="2.14"
        linux-vdso.so.1 (0x00007ffd3cde1000)
        libcrypt.so.2 => /usr/lib64/libcrypt.so.2 (0x00007f18fdd74000)
        libpam.so.0 => /usr/lib64/libpam.so.0 (0x00007f18fdd63000)
        libcrypto.so.3 => /usr/lib64/libcrypto.so.3 (0x00007f18fd800000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00007f18fdd47000)
        libc.so.6 => /usr/lib64/libc.so.6 (0x00007f18fd62f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f18fdec5000)

Which of these do you think has the larger attack surface, or more vulnerable supply-chain? I'm not even trying with that Gentoo build, and I could easily drop pam if I did.

Ahh the old hydrgen drum...
* Extremely low energy density.
* Requires exotic tankage or cryogenics for any attempt to overcome (1)
* Is very, very energy inefficient to produce by any current "green" process (which is why most industrial hydrogen is produced through reforming natural gas).
* Is a complete bastard to work with, as it's low molecular weight means it leaks through just about everything.
* Is arguably more dangerous than either petrol or lithium-based batteries, due to its broad explosive range.

If you want to use solar to run a car, frankly you're better off with batteries for most use cases.

Tell that to people who need to move a couple hundred Kg of tools and equipment for their job... Or travel from outside of urban centres... Or have more than one child... Or a disability...  Or point-to-point freight in general for that matter... Or any number of other situations where tiny vehicles or bicycles are completely inappropriate.

"Pedal power" is part of the solution. It's a long way from the whole story. Likewise rail and electrified public transport.
Just continuing to shout "everyone needs to get on a bike" is exactly as effective as "everyone needs to get an EV", all it does is make transport of everything too heavy or distant to put on a bicycle somebody else's problem.

Driving a 2-ton SUV to get milk is patently ridiculous... But so is insisting that everyone should ditch their private vehicles and "just get a bike".

Indeed. Even leaving out the electric part and comparing diesel trains to diesel trucks it's no contest.
What trains can't do however is roll up outside your house with whatever tat you ordered on amazon 2 days ago. The current lazy online shopper generation is fuelling road transport pretty hard right now.

As ever, what people really want is a "Buy now and fix climate change"/"Spend and feel morally superior" button. Big corporate (and EV manufacturers) are of course all too happy to oblige, and governments to turn a blind-eye to how ineffectual all that is so long as they can be seen to be promoting something with a nice thick coat of green paint on it.

Meanwhile the real elephants in the room (of which private transport is decidedly small-fry) go conspicuously unnoticed, and the solutions we do have go unimplemented, largely due to being expensive or inconvenient - either personally or politically.

Electric traction? Sure. We've had that in various forms for ages, and advances in battery technology have now made it viable (if still a mite explodey) for the private automobile.
Electric traction as the solution to anthropomorphic climate change on the other hand... That's just another episode of the same old consumerist "magic pill" bullshit... See quickfur's excellent coverage above.

Now, that's not to say I wouldn't want to own an electric vehicle. They do have some advantages, particularly where relatively clean electricity is cheap and charging infrastructure isn't woefully inadequate.

However... As far as I can see, it's next to impossible to really own any modern vehicle, regardless of powerplant. So if someone would like to point out an EV that isn't a rolling spyware platform full of obnoxious "safety" features designed explicitly to piss me off and prevent my vehicle from doing what I tell it to, I'm listening...
Otherwise I'll stick to my simple, obedient '70s and '80s tech. No cameras, no GPS, no manufacturer phone-home or remote killswitches, no feature subscriptions, no touchscreens, no driver attention monitoring, and most important of all, no goddamn incessant beeping about every trivial thing.

As for fission vs (fossil fuel) combustion, "clean"ness and timescales... Sure. The only missing component there is that we have some viable solutions for processing and containing spent fission fuel on the table. Carbon capture and storage on the other hand is a complete joke if you take even a cursory look at the numbers (and volume) involved.

If it's already in unstable, 99% of the work is done and the best option is probably a simple backport.

That's only because the binary was built against that version, a problem which will go away by itself if you recompile it as above.

Yeah, nah. Why?
First you need a mouse and a GUI, both of which make it a non-starter for serial console or SSH on headless machines. Then you've got the not-uncommon gpu-driver/KMS shenanigans, and on top of that you're dependent on a particular tool on a particular live disc that you will sooner or later not have handy.

That's without even starting on all the fun to be had with "automatic" repair tools if the system has an unusual bootloader, custom boot configuration or chainloading, RAID, root-on-ZFS, netboot, the list of things such tools will probably either not handle properly or completely louse up goes on.

OTOH, pretty much every bootable GNU/Linux media in existence has mount and chroot, and once you're in that way you have all the tools and existing configuration of the installed OS right there.
You also have the opportunity to fix the problem properly the first time and verify that the installed tools (i.e. update-grub, update-initramfs, dpkg configuration etc.) can reliably update the bootloader for next time.

Why reinvent a perfectly good (and not particularly oft-used) wheel just to make your mouse pointer feel useful?

Or you could just chroot in and do 'dpkg-reconfigure grub-[insert platform]', which is pretty much how d-i installs the bootloader anyways and should suffice for most scenarios.
Personally I have no use whatsoever for refractainstaller, but if I were a betting man I'd say that's what it calls for the bootloader step too.

That's not a bug, it's a design decision.
X was not developed for personal computers, it's fundamentally a graphical mainframe technology. In that scenario the trust model is inverted WRT a PC - i.e. the network is secure, applications are served from the mainframe and implicitly trusted, the terminal running the xserver is not.

X is as secure as it has ever been and (at least for now) it's still getting patches for any newly discovered issues, but the core design concepts don't transfer particularly well to the age of software-as-an-enemy... Then again, as long as you don't run untrusted applications that might want to screenscrape or keylog you, you're fine.

It is, and writing custom shell hacks for every user-session "daemon" that doesn't bother to behave like a daemon because systemd user units exist isn't a particularly elegant or sustainable solution.

If Devuan is going to transition to pipewire following upstream Debian, we're going to need a better answer than "user finds random script / autostart / .xinitrc hints on the 'net" for starting and stopping its services.
IMO some kind of process supervisor (be it part of an init system or standalone) is the only realistic (and reliable) option, and I already mentioned one possibility. Another might be adapting supervise-daemon or runits runsvdir, or running dinit in a user-session context.

This BS is only going to become more common, pipewirwe is just the thin end of this particular freedesktop/redhat/ibm wedge.

FWIW (in case I haven't mentioned it already elsewhere, which I probably have) my current solution is daemon, and these three lines:

/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire /usr/bin/pipewire

/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-pulse /usr/bin/pipewire-pulse

/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-wireplumber /usr/bin/wireplumber

In 3 autostart files (or wherever else you might want them).

Order no longer matters and sleep / while loop hacks are eliminated, because --respawn.
Pipewire not exiting with the user session is fixed (without pkill hacks), because --bind.
Pipewire not doing any of the other things a daemon should do (like writing a pid file or detaching from stdout and forking into the background) is also fixed, and --name and --pidfiles allow for e.g.

$ daemon --list --verbose
cdemu is running (pid 4577) (client pid 4578)
pipewire is running (pid 4573) (client pid 4574)
pipewire-pulse is running (pid 4568) (client pid 4572)
pipewire-wireplumber is running (pid 4547) (client pid 4549)
systembus-notify is running (pid 4583) (client pid 4587)

If you don't want pipewire noise in your xsession log (or want it in it's own logfile), daemon can fix that too with the --output, --stdout, and --stderr switches.

The cost for all this convenience is ~170KB of memory per managed process (on-par with supervise-daemon). Make of it what you will. As much as I like shell, IMO this is a much cleaner solution.

No. I don't reuse passwords, the probability of somebody running a MITM attack on my login to a random forum is miniscule, and even if they did and managed to impersonate me here, who the hell would care?

It is. If you do somehow get redirected to the login form over HTTP (which I haven't seen myself), that's easy to prevent on the browser end with the likes of the HTTPS-everywhere extension.

This ubiquitous bleating about HTTPS with complete disregard for attack surface, user responsibility and basic password hygiene, or even relevance is quite tiring.
Security is a process, not "if [[ ${URL bar} =~ "padlock icon"  ]]; then sleep; else panic; fi".

That script is a simplified version of what Gentoo and Slackware (and likely other non-systemd distros) are using to start pipewire.

PW doesn't daemonise properly, exit with the user's session, or manage it's own instances and ordering, instead relying on systemd user units for all that.
The 1 second sleep is required for reliability, and killing pipewire processes avoids not having sound after a logout -> login (unless you have elogind and KillUserProcesses=yes, which kills everything).

Personally I got rid of all that hacky mess, and am using daemon to manage pipewire (and cdemu, which has the same problems). Binding to the user session requires [e]logind and backporting daemon from unstable, but also neatly solves the "pipewire doesn't exit with session" problem.

TBH the first thing I'd do is see if the system will boot to single user mode (pass "single" or "1" on the kernel command line)... But again, boot issues are difficult to diagnose remotely, so more options more better.
I mention sysrq because when getting a working shell to see what's going on or fix something is the goal, sometimes a large hammer (e.g. "Kernel, kindly kill with fire everything except init") is the most effective tool.