(NOTE: Microsoft owns GitHub so click at your own risk)
But what is showed me that I did not totally realize yet is that:
The California age verification law that is requiring Linux to store an increased amount of information about all users has led to this pull request on systemd to create a space for it to store your age – and the pull request is already merged
Review for this pull request was at least in part completed by “claude”: a closed-source, corporate AI system that is designated by the Government of the United States of America as a Supply-Chain Risk
Does a system that is a designated Supply-Chain Risk according to the United States Government being involved with the development of PureOS mean that in a domino effect PureOS will also be considered a Supply-Chain Risk for the US government? How does that work? Aren’t governments a big customer for Purism?
Not to mention, why do all our systems answer to the people who whimsically answer to the laws in California?
Well… systemd code is there for all to see (if you dare to go to GitHub). Many will go and some will report on what they find, especially if it is nefarious (All Hail Lord Gavin, Dark Lord of Evil!). That’s something. My gripe is not so much with systemd providing a way to pull that info, if present, rather it is with what it gets and how it gets it in the first place. Of course, if other GNU components start requiring that users provide that info, or they start stealing it, then it’s time to fork (or ditch) systemd.
Not specifically PureOS. And it is open to PureOS to package up a different version if it were too problematic.
At a quick read of the discussion, it isn’t strictly true that this has anything to do with the law in CA. It’s a field being added to a database. The real concern is if filling in this field with an authentic value ever became unavoidable. (At the moment, you don’t have to supply a value for the field, much less that it be authentic.)
Another concern is that it just increases the attack surface of every computer on the planet. It’s one more piece of information that you have to take care to prevent leaking out (assuming that there is a real value stored somewhere - and obviously DOB is hugely good for identity theft purposes).
Note that if you have root access on the computer then you can (as currently implemented) set the DOB to any date you like or to no date at all.
As the discussion also observes, not all distros / not all users use systemd - so this isn’t a Linux-wide implementation.
In the end this comes down to a choice that society needs to make:
Either go down the totalitarian route, no more human rights, no more democracy, only state control of everything. In this case it is logical that free software will be illegal because it undermines the totalitarian state control.
Or keep a free society, protect human rights and democracy. In this case, free software is obviously not only allowed but actively encouraged by the state.
In case of systemd specifically, it is free software with a GPL license, so whatever the maintainers put in there a user will still be able to do what the user wants, and remove any bullshit anti-features that are added. I think that legislators who want state control of everything do not yet realize that, and I think that later when they do realize it they will try to make FOSS illegal. It will be interesting to see what happens.
The very first sentence within the very first comment:
Stores the user’s birth date for age verification, as required by recent laws
in California (AB-1043), Colorado (SB26-051), Brazil (Lei 15.211/2025), etc.
Yes, the “as required by recent laws” there is worrying, it sounds like the systemd maintainers think that whoever decided those laws have power over the source code. That’s wrong, the laws have no such power.
True but read more of the discussion around this change. They anticipate the possibility that the law doesn’t become law (too late?) or is abandoned or repealed - but still want to add the field to the database.
if someone abducts Linus Torvalds and points a gun at him and shows him a live stream where they’re pointing guns at his loved ones, and tells him to publish a new build of the kernel using his official credentials or however that works – but where they tell him under duress to put a virus in there – he would put the virus in, right?
Isn’t that how most of us are? There’s some cutoff point where you think, nahhh I’m gonna do what the captors ask and live to see another day and once I do maybe I’ll figure how to fix it?
Companies (or other entities) can put some protection in against that scenario by requiring more than one person to act so that even under duress no one person can e.g. incorporate a virus. It is understood of course that truly motivated criminals (including governments) could abduct multiple people concurrently so as to work around that. A company (or other entity) can make that harder, in this context, by having the required people in quite different geographic locations.
However that clearly isn’t what @Skalman meant. He is talking about the extent of lawful power, not unlawful acts.
As a political move, maybe, but if all you are concerned about is this particular functionality, I’m sure you can nobble it if it is even running.
On my desktop, there is no userdb and hence the userdb is synthesised from other information. Since there is nowhere to store a DOB and in any case my computer has never asked me for one, I imagine that in the synthetic userdb, the DOB field is empty (missing). It is an optional field.
Yes, that means that any future application that refuses to operate without a DOB will not work - but that will probably be exactly the same if you replace systemd with some other mechanism, if the motivation is to avoid the DOB functionality.
It is in systemd-userdbd as far as I know and you can remove it with apt. Currently it is not even installed on Debian, Mobian or PureOS by default. So all your “time to switch” is kinda … childish at a time Purism did not even make a decision to include this package (and at a time there is fight going on to change the law with an exception for the FOSS world).
On my desktop, not only is there no userdb and the package that you mention is not even installed but there is still the synthetic userdb. I don’t know which package implements that but I suspect that you probably can’t remove it unless you remove systemd.
A typical single-user computer probably has no need for an actual userdb and probably won’t have the package that you mention installed.
The way I look at it, DOB is a bit like JavaScript. Yes, you can disable it - but that will be a compromise for you in terms of what functionality stops working.
I don’t say it is no problem, but right now to that point people make 1000 times more about it than it is. Before I switch anything I will watch out how the situation evolves. No need for panic.
Ironically, if you do install the systemd-userdbd package then you get the userdbctl command, which you can use to verify what, if anything, might leak from the userdb - and where the userdb information is coming from and where it could come from. If you don’t have that package then there is only one userdb provider but you are flying blind as to what information it could leak.
My only thought at the moment is: If you have your real name in /etc/passwd and information in that real name cannot be inferred from your username then I would change that real name.
That seems very misleading to me. There wasn’t a vulnerability in systemd. It’s just a matter of fact that it is widely used so it’s an easier target to use during an attack chain.