This is for people whose threat model includes ‘at some point, something could put software on my machine that does a surveillance and puts accurate information into the birthDate field in userdb’ and ‘at some point, something could put software that reads the birthDate userdb field in order to do a surveillance’. And for such people, I expect your threat model should include the same concerns for other fields of userdb as well.
So a better alternative for your threat model is probably
{
systemd.package = pkgs.systemd.override { withUserDb = false; };
# This is already off by default, but hey, what if something at
# some point turns it on in order to do a surveillance?
services.userdbd.enable = lib.mkForce false;
}
And that keeps you from having to trust Jeffrey Sardina as a software vendor as well, since your threat model probably causes you to want to trust as few vendors as possible.
Yeah, this makes a lot of sense. Its more of a temporary holdover until I find a better solution. I understand some folks are packaging liberated systems (or are talking about it) so that would vd the ideal.
Thankfully I can use this config to commit pin to something that i can verify until that happens
What this should make you realize is that the people who made that fork have absolutely no clue about systemd, and that you probably shouldn’t be using that fork because this means that they aren’t qualified to maintain it.
It’s also stupidly tunnel-visioned. Are y’all seriously more worried about the birth date field than the full legal name field?? The fork literally touches no other fields, many of which are likely far more valuable for surveillance. This is literally just virtue signaling with zero actual design behind it.
Seriously, if you are worried, just disable the userdb as @rhendric suggests. That’s both more sensible and removes more - again, empty - fields with PII.
Hey friend, I have no intent on spreading disinformation or fear, but I also see where you’re coming from, and I can see how my post read that way.
This was the result of an experiment on my end to see if it was possible to repack systemd in a way that felt like it was sidestepping an issue with the upstream project, whose maintainers appeared unwilling to patch out these tools themselves. I can see that it was hasty and lacking some important context. I’ve added a note explaining my train of thought.
Thanks for the clarification and for taking a constructive feedback on board.
I think the key point is that the discussion produced better technical context and a better solution. That is a positive outcome, even if the original proposal was not the right one.
Experiments are essential part of how people test ideas and learn, so I would not worry too much about that. What matters is that the thread helped surface better information, clarified the trade-offs, and pointed towards a more sensible approach.
Personally, I would also still be much more comfortable relying on upstream systemd with the relevant flag disabled than on a fork with no established track record, but that aside, I think the thread has now served its purpose and that seems like a good place to leave it.
I want to explicitly second what @drupol says. Experimentation is welcome, and the outcome is good.
Thanks for listening to the feedback, and caveating your post; I was most worried about it leading others into using this fork. Systemd is a terrifying thing to compromise at scale.
But yes, NixOS makes it really easy to sub out software. That’s what makes it so cool
