mozz

Sounds like serious hardware problems (bad memory sounds highly likely if that's what memtest is telling you). Replace the faulty hardware before changing out any software, and before the badness "spreads"; you may already have corrupted a certain amount of the data / installed software on your disk by writing back data after the bad memory corrupted it, if you've been running on the broken hardware for that long.

I wish Debian had better support for software that wants to do its own package management.

They do it a little bit with python, but for most things it's either "stay within the wonderful Debian package management but then find out that the node thing you want to do is functionally impossible" or "abandon apt for a mismashed patchwork of randomly-placed and haphazardly-secured independently downloaded little mini-repos for Node, python, maybe some Docker containers, Composer, snap, some stuff that wants you to just wget a shell script and pipe it to sudo sh, and God help you, Nvidia drivers. At least libc6 is secure though."

I wish that there was a big multiarch-style push to acknowledge that lots of things want to do their own little package management now, and that's okay, and somehow bring it into the fold (again their pyenv handling seems like a pretty good example of how it can be done in a mutually-working way) so it's harmonious with the packaging system instead of existing as something of an opponent to it. Maybe this already exists and I'm not aware of it but if it exists I'm not aware of it.

I don't see why it wouldn't. I think for gentoo, you want to check if you need any security updates with:

emerge --sync
emerge gentoolkit
glsa-check -l affected

(Edit: Also, as a general rule -- don't type stuff as root just because I or some other random person on the internet tells you to; check the man page or docs to make sure it's going to do something that you want it to do first.)

All Linux systems will be very likely vulnerable to this if they're not they're patched with the fix. Patched systems will not be vulnerable. That's true for Debian and Ubuntu, as it is for any Linux system. The commands I gave are determining whether or not you're patched, on a Debian or Ubuntu system.

What distro are you running? I can give you commands like that for any Linux system to determine whether or not you're patched.

Easiest answer:

sudo apt udpate
sudo apt upgrade

If it upgrades some stuff, you were vulnerable, but you no longer are. If nothing upgrades, then you were already all good.

If you're doing that regularly, then your core system will generally be patched fixing almost all exploits in your core system, including this one. If not, you're vulnerable to this exploit and likely a whole bunch more stuff.

Edit: That's the simplest answer but if you're curious you can do a double-check for this particular vulnerability with apt changelog libc6 - generally speaking you won't see recent changes, but if a package has been recently updated you'll see a recent fix. So e.g. for this, I see the top change in the changelog is the fix from a couple weeks back:

glibc (2.36-9+deb12u4) bookworm-security; urgency=medium

  * debian/patches/any/local-CVE-2023-6246.patch: Fix a heap buffer overflow
    in __vsyslog_internal (CVE-2023-6246).
  * debian/patches/any/local-CVE-2023-6779.patch: Fix an off-by-one heap
    buffer overflow in __vsyslog_internal (CVE-2023-6779).
  * debian/patches/any/local-CVE-2023-6780.patch: Fix an integer overflow in
    __vsyslog_internal (CVE-2023-6780).
  * debian/patches/any/local-qsort-memory-corruption.patch: Fix a memory
    corruption in qsort() when using nontransitive comparison functions.

 -- Aurelien Jarno <aurel32@debian.org>  Tue, 23 Jan 2024 21:57:06 +0100

Oops. I totally missed that. I revised my comment to reflect it.

Use a restricted account with an un-passphrased key is probably by far the easiest way. You could also use rsyncd, but you'll have to fool with a whole bunch of stuff. The work involved will probably be a superset of just doing a restricted account for the rsync process to use for rsync-over-ssh.

Edit: I had totally missed that the issue was passphrase of the key, not password

$ while true; do echo Hello, I updated the header; sleep 5; done &
[1] 1631507
$ Hello, I updated the header
sleep 30; echo Sleep is done.
Hello, I updated the header
Hello, I updated the header
Hello, I updated the header
Hello, I updated the header
Hello, I updated the header
Hello, I updated the header
Hello, I updated the header
Sleep is done.
Hello, I updated the header
$ kill %1
[1]+  Terminated              while true; do
    echo Hello, I updated the header; sleep 5;
done
$

Edit: I'm fairly confident now that you're just thinking the loop will stop when you run oogabooga, but that's not how it works. That up above is how it works; the loop keeps going during the sleep with them both going on the same terminal, then after the sleep process terminates, I kill the loop, but for the whole 30 seconds previous, they were both going. It'll be the same with oogabooga. This the situation you're asking about, yes?

I'm having trouble understanding the question.

while true; do update-header-bar-or-whatever; sleep 5; done &
oogabooga

... will run the header update every 5 seconds, while oogabooga is running. Is that what you want?

Who is fearful? I glanced over this thread and I didn't see a lot of fear; it's mostly just people observing the dishonesty.

Maybe there is or isn't a reason to worry about Facebook coming into the community, but discussing it (at least as I've seen in this thread) doesn't mean either anger or fear. It's just discussing. It's a good thing to do.

I think it's doubtful that they actually are. If they were actually reaching out to any Mastodon "leaders," I think the leaders would be saying something about it and posting the communications.

Yeah, the whole article is like that. Not only is the writer apparently clueless enough to get basic facts about Mastodon wrong, but each one is wrong with a flavor of a Facebook-favoring way (like implying in several different subtle ways that Mastodon includes some sort of harmful behavior or some limitation, and we need to carefully monitor to make sure it doesn't negatively impact any Facebook users, and that's the issue). And, there's absolutely no curiosity or follow-up question even after statements that are clearly inviting them.