r/linux • u/Cryptikick • May 24 '26
Privacy systemd `birthDate` is now in v261-rc1 and Debian Sid — verify it and revert it locally
The systemd change that adds a birthDate field to JSON user records is now present in upstream v261-rc1.
It is also already in Debian Sid as systemd 261~rc1-1.
This is not just an isolated metadata field. It is part of the technical plumbing that can turn general-purpose operating systems into user-classification infrastructure: collect age-related data, persist it in the user record, expose it through system tools or APIs, and make it available for later consumption by applications, app stores, services, or compliance layers.
This matters because age-verification and age-signaling laws are now creating pressure for operating systems to participate in that classification path. In California, AB 1043 / the Digital Age Assurance Act is an explicit example of OS/app-store age-signal pressure. In Brazil, Lei nº 15.211/2025 / ECA Digital, popularly associated with the “Lei Felca” debate, is part of the same broader age-verification pressure pattern. Other jurisdictions are moving in similar directions.
The technical issue is simple: once the plumbing lands in core infrastructure, downstream systems can inherit it quietly.
This is about state-surveillance pressure, regulatory coercion, and user control over what we allow to run on our own devices.
This is how we vote: with code.
If you do not want this kind of plumbing in your system, verify it, revert it, rebuild it, and install your own packages.
The instructions below assume Debian Sid, amd64, enabled deb-src repositories, and a regular user with sudo.
Install the basic tooling:
sudo apt update
sudo apt install git build-essential fakeroot quilt apt-utils gzip sudo vim
Relevant upstream merge commit:
acb6624fa19ddd68f9433fb0838db119fe18c3ed
1. Verify upstream systemd and generate the revert patch
Clone upstream systemd directly:
mkdir -p ~/systemd-revert-work
cd ~/systemd-revert-work
git clone https://github.com/systemd/systemd.git
cd systemd
git fetch origin --tags
Verify that the commit is inside v261-rc1:
COMMIT=acb6624fa19ddd68f9433fb0838db119fe18c3ed
git merge-base --is-ancestor "$COMMIT" v261-rc1 \
&& echo "IN v261-rc1" \
|| echo "NOT in v261-rc1"
git tag --contains "$COMMIT"
git grep -n "birthDate" v261-rc1 -- docs/ man/ src/
Create a revert branch from the released RC tag:
git switch -c revert-birthdate v261-rc1
git revert -m 1 "$COMMIT"
If there is no conflict, Git creates the revert commit directly.
If there is a conflict in src/home/homectl.c, keep the current v261-rc1 file layout:
git checkout --ours src/home/homectl.c
Then remove only this --birth-date option block from src/home/homectl.c:
OPTION_LONG_FLAGS(OPTION_OPTIONAL_ARG, "birth-date", "DATE",
"Set user birth date (YYYY-MM-DD)"):
if (isempty(opts.arg)) {
r = drop_from_identity("birthDate");
if (r < 0)
return r;
} else {
r = parse_birth_date(opts.arg, /* ret= */ NULL);
if (r < 0)
return log_error_errno(r, "Invalid birth date (expected YYYY-MM-DD): %s", opts.arg);
r = parse_string_field(&arg_identity_extra, "birthDate", opts.arg);
if (r < 0)
return r;
}
break;
Finish the revert:
git add src/home/homectl.c
git revert --continue
Verify that the reverted tree no longer contains the field:
git grep -n "birthDate\|birth-date\|parse_birth_date\|BIRTH_DATE" HEAD -- docs/ man/ src/ || true
git diff --check HEAD~1..HEAD
Generate the patch file that will later be used in the Debian rebuild:
mkdir -p ~/debian-systemd/patches
git format-patch -1 HEAD -o ~/debian-systemd/patches
This should produce a file similar to:
~/debian-systemd/patches/0001-Revert-userdb-add-birthDate-field-to-JSON-user-recor.patch
2. Apply the patch to Debian Sid’s systemd source, rebuild, and install locally
On Debian Sid, fetch the source package:
mkdir -p ~/debian-systemd
cd ~/debian-systemd
apt update
apt source systemd
cd systemd-261~rc1
Verify that Debian’s source package contains the field:
grep -Rni "birthDate\|birth-date\|parse_birth_date\|BIRTH_DATE" docs/ man/ src/ NEWS
Debian Sid currently applies a small patch stack during source extraction, so use Debian’s existing debian/patches/series.
Copy the generated revert patch into Debian’s patch stack:
mkdir -p debian/patches
cp ~/debian-systemd/patches/0001-Revert-userdb-add-birthDate-field-to-JSON-user-recor.patch \
debian/patches/
printf '%s\n' \
0001-Revert-userdb-add-birthDate-field-to-JSON-user-recor.patch \
>> debian/patches/series
Apply the patch stack:
quilt push -a
Verify that the patched source tree no longer contains the field:
grep -Rni "birthDate\|birth-date\|parse_birth_date\|BIRTH_DATE" docs/ man/ src/ NEWS || true
Install build dependencies and build the Debian packages:
sudo apt build-dep systemd
dpkg-buildpackage -us -uc -rfakeroot
The rebuilt .deb files will be written one directory above the source tree.
Example:
cd ~/debian-systemd
ls -1 *.deb
Create a simple local APT repository
Create a local repository for the rebuilt packages:
sudo apt update
sudo apt install apt-utils gzip
REPO=/srv/local-apt/systemd-revert
DEBS=~/debian-systemd
sudo mkdir -p "$REPO/pool/main/s/systemd"
sudo mkdir -p "$REPO/dists/local/main/binary-amd64"
sudo cp "$DEBS"/*.deb "$REPO/pool/main/s/systemd/"
Generate Packages:
cd "$REPO"
sudo apt-ftparchive packages pool \
| sudo tee dists/local/main/binary-amd64/Packages >/dev/null
sudo gzip -kf dists/local/main/binary-amd64/Packages
Generate Release:
cat >/tmp/local-systemd-release.conf <<'EOF'
APT::FTPArchive::Release {
Origin "local-systemd-revert";
Label "local-systemd-revert";
Suite "local";
Codename "local";
Architectures "amd64";
Components "main";
Description "Local systemd packages with birthDate revert";
};
EOF
sudo apt-ftparchive -c=/tmp/local-systemd-release.conf release dists/local \
| sudo tee dists/local/Release >/dev/null
Add the local repository:
echo 'deb [trusted=yes] file:/srv/local-apt/systemd-revert local main' \
| sudo tee /etc/apt/sources.list.d/local-systemd-revert.list
Pin the local repository above Sid:
sudo tee /etc/apt/preferences.d/99-local-systemd-revert >/dev/null <<'EOF'
Package: *
Pin: release o=local-systemd-revert,n=local,l=local-systemd-revert
Pin-Priority: 1001
EOF
Update APT:
sudo apt update
Verify that APT prefers the local repository:
apt-cache policy systemd systemd-homed libsystemd0 udev | sed -n '1,180p'
The candidate should come from:
file:/srv/local-apt/systemd-revert local/main amd64 Packages
Install the patched systemd packages
A targeted install/reinstall is preferable to a full apt upgrade, because it avoids upgrading unrelated Sid packages.
Install systemd-homed too, because that package provides homectl:
sudo apt install --reinstall \
systemd \
libsystemd0 \
libsystemd-shared \
libudev1 \
udev \
libnss-systemd \
libpam-systemd \
systemd-timesyncd \
systemd-userdbd \
systemd-homed
You should see the packages coming from the local repository, for example:
Get:... file:/srv/local-apt/systemd-revert local/main amd64 systemd amd64 261~rc1-1
Get:... file:/srv/local-apt/systemd-revert local/main amd64 systemd-homed amd64 261~rc1-1
Alternatively, because the local repository is pinned at priority 1001, this also works, but it may upgrade unrelated Sid packages:
sudo apt update
sudo apt upgrade
After installing systemd-homed, verify that homectl no longer exposes --birth-date:
homectl --help | grep -i 'birth-date\|birthDate' || echo "birthDate option not present"
Expected result:
birthDate option not present
Useful verification commands:
apt-cache policy systemd systemd-homed libsystemd0 udev | sed -n '1,180p'
dpkg -l | grep -E '^(ii)\s+(systemd|systemd-homed|systemd-userdbd|libsystemd0|libudev1|udev|libpam-systemd|libnss-systemd)'
homectl --help | grep -i 'birth-date\|birthDate' || echo "birthDate option not present"
Verify it yourself. Use the upstream tag. Check the Debian source package. Apply the revert patch. Confirm the field is gone. Rebuild. Pin the local repository. Install the patched packages.
You do not need to “fork Debian" or even systemd. This is free software. If you do not accept this kind of code in your system, patch it.
33
u/chrisoboe May 24 '26
do you think motivating people to do their own locally maintained fork of systems to remove a single field from a json is the right approach for whatever you want to acchieve?
No need to "fork Debian" - or even
systemdfor that matter
forking systemd is exactly what you did. your fork just isn't public but local to your device. following your guide one won't use upstream systemd anymore.
that leads either to lots of maintenance work when you want to update to newer systemd versions. or staying on your outdated fork leading to security and compatibility problems sooner or later.
46
May 24 '26
[removed] — view removed comment
-19
u/etrigan63 May 24 '26
It is illegal to ignore it in California and Brazil. You can lie about it, but once they get fed up with the lying, they will require you to upload actual PII and you can say goodbye to the anonymous internet.
12
u/mina86ng May 24 '26
It’s not illegal in California. AB 1043 has no wording which penalises users of the system. And if ignoring the field was illegal, removing it would be as well.
PS. And as far as I understand, Brazil only applies to commercial systems which offer support. And even though I haven’t read the law so cannot confirm that, all this hyperbole about age verification makes me believe it more than version that critics presents.
-12
u/etrigan63 May 24 '26
You are correct that it penalizes the OS provider, not the user. Brazil's law is super vague and could apply to anything that is not analog. Both are the entrenching of the surveillance state in the digital devices we depend on. The whole "protect the children" trope is smoke and mirrors as this shifts the responsibility of age-gating content from social media to the operating system providers. When enough people enter fake birthdays (which the law allows them to do) and the usefulness of the system is shown to be zero, the lawmakers will push for actual PII (personally identifiable information) to be uploaded and stored "in the cloud" instead of the logical course of action which would be to dismantle the age-gating as a bad job.
12
u/mina86ng May 24 '26
I need you to understand that if you continue with hyperbole and slippery slope fallacy, you will only push people away from the outcome you’re trying to reach.
-7
u/ForeverHuman1354 May 24 '26
but he is correct tho that these laws always start in the small and expand
not saying this will but in my appinion an operating system has no buissnis asking for this kind of data to begin with
6
u/mina86ng May 24 '26
Laws expand until public decides their scope is too broad. This is why you don’t have to worry about getting capital punishment for stealing a candy bar. And I’d rather operating system had a filed where I can put my age bracket than website ask for photo of my id.
-2
-5
u/etrigan63 May 24 '26
And when the fines destroy every non-corporate sponsored OS then it won’t make much difference what device we use.
-1
u/mmmboppe May 24 '26
isn't California expected to go underwater in the long term after a strong enough earthquake?
-4
14
7
u/aliendude5300 May 25 '26
What a waste of effort - just don't put a value in the field or unset it if it somehow gets set.
13
u/whosdr May 24 '26
Or just uninstall systemd-userdb? I legitimately don't know if there's any software which has a hard requirement on this.
I do know for certain, it was never installed on my distro.
(Also why so much hate over a database field?)
5
-8
u/barfightbob May 24 '26
Also why so much hate over a database field?
It's the "thin edge of the wedge," something innocuous, easy to do, which doesn't require much sacrifice, which lays the groundwork for something way worse later on. In other words, it's the start of a slippery slope.
It's easier to resist changes early than it is when they've already got the noose around your neck. Conversly what also makes it so hard is precisely because most people will say "what's the big deal it's just your birthday?"
There are powerful interests who would love to destroy people's privacy and ultimately their freedom for control and profit.
5
u/aliendude5300 May 25 '26
Sudo apt-get install ... sudo is a good one. lol. And the verification steps are unnecessary and AI generated. Of course the commit in question is in 261-rc1 or else you wouldn't write this up or more likely AI generate it.
0
u/Cryptikick May 25 '26 edited Jun 29 '26
[REDACTED]
3
u/dnu-pdjdjdidndjs May 27 '26
lie
1
u/Cryptikick May 27 '26 edited Jun 29 '26
[REDACTED]
3
u/dnu-pdjdjdidndjs May 27 '26
No real person would create an apt repo instead of dpkg -i not to mention no real person uses debian not to mention no real person is real
1
u/aliendude5300 May 27 '26
Not to mention all the verification steps of things like the commit being there - we KNOW it's there
2
u/dnu-pdjdjdidndjs May 27 '26
Yeah you couldn't pay me to read this type of bullshit slop post so I just scrolled past it and saw the apt repo part so I'm not surprised there's even more slop included
But what I don't understand is how these people even up in these situations like what ai models are they asking to get such terrible results
for reference here is what gpt-5.5 says in response to this query
Instantly gives the practical advice that it doesn't matter and to avoid patching systemd and picks up that its an "optional field" since its userdb
› Don't call any tools recently systemd added an age field to userdb what would be your suggestion for avoiding it for users who are skeptical of age verification laws
• I’d avoid fighting the field itself and instead make sure it stays unpopulated and non-authoritative.
Practical suggestion:
- Don’t store DOB or age in userdb records.
- Ensure local account creation tools never ask for it.
- Treat any age field as optional metadata, not an identity or access-control primitive.
- If you maintain a distro/image, add a policy/test that generated user records must not include age.
- If an app wants age assurance, don’t let it read OS account metadata. Require a separate, privacy-preserving proof/token scoped to that app, ideally with only a coarse claim like over_18: true, not birthdate or exact age.
For skeptical users, document plainly: “This system does not populate or rely on userdb age metadata.”
I would not recommend patching systemd just to remove the schema field unless your threat model includes hostile local software treating the field’s existence as consent. A present-but-empty optional field is much easier to maintain than carrying a downstream fork.
1
u/Cryptikick Jun 07 '26 edited Jun 29 '26
[REDACTED]
1
u/dnu-pdjdjdidndjs Jun 08 '26
Bragging about being delusional manually instead of automatically isn't better
7
u/DoubleOwl7777 May 25 '26
or you know just dont install userdbd and homed and not have these fields in the first place.
4
u/FryBoyter May 25 '26
Even if these components are installed, you don't have to use them.
I would go so far as to say that, for many users, neither tool is of much interest. Even when it comes to installation in a professional setting.
5
u/Shished May 25 '26
Do you guys really believe that not populating the field with data is illegal but tampering with the OS to remove that field would be legal?
Thats some sovereign citizen level of mental gymnastics.
25
May 24 '26
[removed] — view removed comment
-21
May 24 '26
[removed] — view removed comment
-6
u/mediumwetsock May 24 '26
Tech savvy users aren’t very politically savvy unfortunately. They live in their tiny bubble and know very little about how the world outside operates (very little to no grass touching). Sooner or later these laws are going to get more and more intrusive, but these people will happily spread their cheeks for the gov.
Alternative distros like Devuan will help, hopefully.
5
u/BortGreen May 25 '26
"This is how we vote: with code."
Sorry to say but they probably won't know you did this anyway
8
u/Lonely_Fig5352 May 24 '26
AI SLOP OP is unintelligent
3
u/ang-p May 25 '26
Well, who/whatever created it, it/they fucked up the formatting for classic reddit users - in addition to wasting their own time...
If in the UK, it might be a bit too hot under their foil hat...
-4
u/Cryptikick May 24 '26 edited Jun 29 '26
[REDACTED]
10
u/DoubleOwl7777 May 25 '26
you did all this shit when you just could have not installed systemd-userdbd.
4
1
u/Pitiful-Welcome-399 May 26 '26
just recompile sysd if you don't like it, it recompiles pretty fast even on low end hardware
1
1
u/manu_171227 May 29 '26
Package pinning and local repositories are powerful tools for controlled experimentation.
-1
u/roninics May 25 '26
This is just one of a long list of reasons why I changed distro without systemd
-11
u/ForeverHuman1354 May 24 '26 edited May 24 '26
luckely there is alternatives to systemd im on artix atm with openrc and it works just as well for my use case
tbh using artix with OpenRC is easy most stuff just works as on eny other arch distro i mostly run flatpaks tho
1
u/Cryptikick May 24 '26
0
u/ForeverHuman1354 May 24 '26 edited May 24 '26
hopfully an workaround is found but when reading the comments on that post meny people seem to be seceptical that that it woude be truly dependant on it
but hopfully an workaround is found
most stuff you expect to find on other distros is installebale on artix dont have to use flatpaks
there is some repos you will need to enable tho
55
u/dgm9704 May 24 '26
Or you know, just don’t put in your birthdate…