Call to contributions

Hey CI/CD Free Software Fedi,

I plan to move the s6-overlay repository away from Github. Probably to Codeberg.

Problem is, the build uses Github Actions, which I'm not fluent in (it was written by @jprjr , thanks again!) - and Forgejo Actions use a different format.

Learning these languages would be way too much time investment from me, for a small benefit.

So I'm asking for help from knowledgeable people. Could someone please take a look at https://github.com/just-containers/s6-overlay/blob/master/.github/workflows/release.yml and convert it to a file that would work on Codeberg's Forgejo? It's a small file, but it uses a build matrix, targeting several architectures.

What would be even more awesome is if Forgejo could create symlinks to artifacts (in order to have the same artifact exposed under several names). That would allow me to work on long-requested features. If not, no big deal.

Thanks a lot!

(Edit: typo)

Instead of using ethical concerns as a basis for policy, we should justify policy on the basis of how something is impacting our ability as a project to deliver a really great programming language.

My brother in tech, you're not going to believe what makes a project really great.

Rustaceans are not okay
https://chaosfem.tw/@Athena/116578993491995353

RE: https://flipboard.com/@theverge/the-verge-5hobbaa8z/-/a-RKgzzvvtTnadjMq82fXG_A%3Aa%3A43611565-%2F0

Oops! Teeheehee. Our bad. No hard feelings I hope 🥺

Sam Harris has turned into a bigoted pro-genocide Zionist.
Richard Dawkins has turned into a bigoted islamophobe suffering from AI psychosis.
Daniel Dennett and Christopher Hitchens are dead. Judging by what the other two horsemen have become, I suspect it's the better outcome. They didn't have time to turn into villains.

And new figures of atheism are mostly embedded with rationalist movements, which are way too close to TESCREAL for comfort.

Is there anyone representing a humanist, progressive atheism these days?

That was way faster than expected! Some person read my emergency ticket sent last night (from logged out), and I seem to have been convincing enough because they restarted the server for me, and now everything is working again. 🥳

Guess I won't have these 10 days of forced vacation. 😔

Now to take measures so that it doesn't happen again...

skarnet.org will be down until further notice - it may take up to 10 days (!)

I wanted to reboot the server on a newly tailored kernel to avoid CopyFail shenanigans. The shutdown failed right before rebooting (because of a small oversight in s6-linux-init that is easy to fix and will not impact anyone else). Normally that wouldn't be a problem: log in to the web interface to the VPS administration, press the reboot button, done.

Except, Gandi added 2FA since I last logged in, and did not notify their users. And they decided that by default, the verification code would be sent to the registered primary e-mail address.

My registered primary e-mail address is hosted on skarnet.org. Because it was never a possibility that it would be needed for the bootstrap chain. Except that now it is, and I can't access it.

This is the dumbest catch-22 in the history of catch-22s. And the recovery procedure, when you have to prove your identity when writing to the support outside of a logged in account, can take up to 10 days. And tomorrow is a holiday. Fuck me, I guess.

I should have paid more attention, but the consequences of my not paying enough attention should definitely not be so vast, and I have choice words for several of the decisions that were made.

A new Git version just dropped and it comes with a new experimental `history` command!

`reword` can be used to change commit messages and `split` can untangle a single commit into multiple ones.

No more interactive rebase. 🎉

https://github.blog/open-source/git/highlights-from-git-2-54/

RE: https://infosec.exchange/@SecureOwl/116404712213309413

This thread is WILD. One more proof that data protection on the larger 'net is an absolute joke.

Hot take: anyone who believes there is no artistic value in programming is someone whose judgement about code I do not trust or value. Not on the artistic side, and not on the engineering side either.

So, systemd's NOTIFY_SOCKET readiness notification mechanism has a sort of authentication mechanism by pid: it doesn't like it when the notification is sent from another process than the main one, unless you add the NotifyAccess=all directive. Okay, fair.

Except that even with this directive, it still can fail for some reason:

if an auxiliary process of the unit sends an sd_notify() message and immediately exits, the service manager might not be able to properly attribute the message to the unit, and thus will ignore it, even if NotifyAccess=all is set for it.

Huh? Even if it the supervisor wants to check that the MAINPID= given in the message is the relevant unit, it shouldn't need the notifier process to still be around, but, let's ignore that for now. So, it has a barrier mechanism to tell the notifier to stick around until the supervisor has acknowledged it. What is that barrier mechanism? The notifier passes an fd to the supervisor via SCM_RIGHTS in the notification message, and when the supervisor closes that fd, it means it has acked the notification, and the notifier can now exit.

That's right, folks: it's a notification that the notification has been received!

There are two mistakes here: 1. the supervisor doesn't need the notifier process to be alive when processing the notification, and 2. NOTIFY_SOCKET being a socket means that any process can connect to it so the supervisor needs to authenticate the relevant unit.

And that is how a bad design decision cascades into a maze of complexity and inefficiency, and a pain to implement. Unless you're willing to use libsystemd to get access to sd_pid_notify_barrier(), good luck getting this to work right.

(systemd people will say this is conspiratorial, but if they wanted to force users to link against libsystemd, they wouldn't behave differently. But I really don't care if it's intentional or not. If it's not intentional, it's just terrible engineering.)

What would be a simpler way to handle all this? Have the supervisor run the unit with a pipe from the daemon to the supervisor, not a socket anyone can connect to. Processes that can write to the pipe are the ones that can inherit it, which means they're necessarily part of the same unit. No need for authentication via pid. When the supervisor receives a certain token on the pipe (e.g. a newline), it means that the daemon is ready. In the daemon or any process notifying on its behalf, that spells: write(fd, "'\n", 1); and that's it.

In other words: the s6 readiness notification protocol, which is exactly what is described in the above paragraph, is as efficient as systemd's synchronization protocol for its notification protocol.

The real tragedy is that when you go through systemd with a looking glass, every part of it is this way. It still works, and nobody notices the inefficiencies because modern machines are blazingly fast, but it is. so. bad.

My mother has worked at UNESCO for all her active life, so like all the UN staff, her retirement pension is managed by the United Nations Joint Staff Pension Fund (UNJSPF).

She's a very smart, but by and large Not Online woman. She does not spend her time obsessing over the latest political or societal catastrophes as we do here; she enjoys music and poetry, plays the piano, and visits Italian museums instead. (Yeah, she's way smarter than I am.)

Today, she sends me this article: https://www.unjspf.org/newsroom/unjspf-showcases-blockchain-based-digital-identity-solution-at-government-blockchain-association-executive-roundtable-on-capitol-hill/ and says: "what typically nonsensical babble 🙄"

Except, folks, it's not nonsensical babble. I understood every sentence in the article, and if you read it, chances are you will too. And it chilled me to the bone.

The article is a best-of all the harmful bullshit of the past decade. I broke it down for her:

• Blockchain: last decade's buzzword, useless in this context: scam
• Digital identity solution: data gathering, surveillance technology
• Prevent fraud, waste and abuse: Trumpspeak meaning cutting public services and embezzling public money
• Biometrics, geolocation: surveillance and disenfranchisement technology
• Artificial intelligence: the current speculative bubble, which will probably crash soon, taking down a huge chunk of the economy with it, and that would be the good outcome
• Deepfake detection: Orwellian speak, AI is used for deepfake creation, and said "detection" is disenfranchisement technology
• "Ensuring the authenticity of our beneficiaries": disenfranchisement technology
• Kiosk mode: disenfranchisement
• Post quantum: valid in certain specific contexts, this one is not that, here it's just a buzzword: scam
• Trustworthy digital ecosystem: trustworthy for whom? Certainly not the users.

I concluded by saying that after reading the article, I was seriously worried for the future of her pension, and if there was the slightest possibility for her to move away from the UNJSPF, she should jump on it. She believed me (told you, she's smart) but answered that there was no way to move, she's stuck with them.

And she's not alone. All the retired UN staff is in the same boat. I don't know what they can do. I don't know what I can do.

s6 will never add an age tracking field anywhere.

s6-rc 0.6.0.0 and s6-frontend are out!

This new version of s6-rc provides the user with a framework to store and organize their service definition directories, and utilities to craft sets of services that they want to appear in their service database. It is the engine that runs under s6-frontend.

s6-frontend is a user-friendly interface to all the parts of the s6 ecosystem. It provides a single s6 command, that pilots the s6 and s6-rc packages while hiding gritty policy details, and makes the service manager easy to configure and operate. It is the penultimate step before making s6 a full init system that distributions can integrate.

Thanks to @nlnet for funding this work!

On to the last step: writing generic essential service definitions that can boot a modern system. Cheers!

https://skarnet.org/software/s6-frontend/

Bottom line: we should stop asking for a diagnosis to give people accommodations!
If someone tells you they need to use a noise cancelling headset to focus, let them. If someone tells you they need some quiet time in the middle of the day, let them.

This is your regular reminder that doas suffers from the exact same conception flaws as sudo.

• It is a suid root binary.
• It parses, as root, a text file that contains global instructions for what user is allowed to run what command as what other user. There is quoting involved. The syntax is not absolutely trivial (though simpler than sudo's).

Is doas better code? Probably. I trust that it's cleaner than sudo; its configuration file syntax certainly is. Has it been audited more, is it more trustworthy than sudo? Definitely, it comes from OpenBSD, and if there's one thing OpenBSD does well, it's that.

But does it solve the fundamental problem that causes the issues with sudo?

No. It does not.

If you use doas, you are not "choosing the more secure tool", at least not by its conception. You are simply trusting doas to do a better job of not being buggy while performing the exact same tasks as sudo in the exact same dangerous environment.

It is not a bad choice. You are probably right to do that. But you should know what you are doing exactly.

If you choose to use sudo-rs instead, you are still running a suid root binary that performs complex parsing, without the advantages of the simpler doas syntax or the experience of OpenBSD in hardening. You get the benefit of memory safety, but other kinds of bugs are still possible in Rust. You are basically trusting the sudo-rs authors to write a non-buggy sudo - and even with Rust's help, it is probably more difficult than writing a non-buggy doas.

It's a pick your poison situation.

If you want real security instead, you should reconsider your approach to privilege gain, study your use cases, and implement tailored specific solutions. Yes, it is a lot more work, but privilege gain is the single most dangerous thing you can do on Unix, so hardening it takes work.

Another day, another attempt to rewrite the world a little bit less and use an existing standard tool, because that's what they were made for...

... and another failure. kill does not have a portable way of sending a numbered signal to a process. When you have a signal number, you can use the kill() system call to send that signal to a process, but not the kill command-line utility.

Yes, I understand that you are supposed to address signals by their name and not by their number, but since the system call uses numbers in the first place, would it have been so horrible to allow the command line to do the same? And so, I am now writing a s6-frontend-kill command line helper. :blobfoxfacepalm:

When will they shove AI into it?

https://www.phoronix.com/news/Debian-APT-Will-Require-Rust

POSIX allows an implementation of getpgid (https://pubs.opengroup.org/onlinepubs/9799919799/functions/getpgid.html) to fail when the process calling getpgid() is not in the same session as the process it wants the pgid of.

Reasonably, Linux and FreeBSD ignore that part, and simply return the pgid, no matter who asks.

But OpenBSD sees a standards-conformant opportunity to be a giant pain in the ass, so it has to jump on it. And so, when A calls getpgid(B) and B is in a different session, it returns -1 EPERM, even when A and B have the same uid and gid, and it would be perfectly legit for A to send signals to B and its whole process group.

The behaviour is the same for getsid, of course.

As a consequence, s6-supervise on OpenBSD is unable to target the process group of its supervised process, which disables one of its mitigation strategies for misbehaving daemons that leave children behind when they die. And since OpenBSD doesn't have cgroups, that doesn't leave many mitigation possibilities.

I am curious of why POSIX allows this. It seems to go against the common Unix principle that the uid is the key to which process is allowed to communicate with which.

It might make sense to forbid setpgid from the outside, but forbidding reading the pgid feels wrong. Especially since it's defeatable: since I control the parent and child, the child can getpgrp() and communicate its pgid to the parent. But that's a lot of work for something so niche that only breaks on OpenBSD.

I am starting to believe that OpenBSD's reputation for security is mostly due to the fact that no rational person bothers to port software to it.

(Edit: typo)

If you know anything about LLM crawlers, you know that most of them are unethical pieces of shit. They want to download all your content, they do not respect robots.txt, and they know they're doing something wrong because they try their hardest to avoid being blocked. They attack you from large swaths of IPs, among which residential ones, so you can't pre-ban IPs or networks. Usual countermeasures to Internet abusers do not work, and that's why alternative solutions like Anubis (https://anubis.techaro.lol/) exist and are widely deployed.

Problem: I can't use Anubis on my setup.

The skarnet.org project is, in a large part, an experiment in building a different software stack, with as little code as possible, and extracting the most possible value for that amount of code. I'm very happy with what I've built so far, but it also means there are limits, and things I cannot do, because it would go against the skarnet.org design entirely. Deploying Anubis is one of these things. 2/8