I searched the archives and didn’t find a mention of this even though it’s a little old.
TL;DR /etc/machine-id is a way of identifying the host. If you are concerned about that I believe that you can safely regenerate it with the following command:
sudo /bin/rm /etc/machine-id; sudo /usr/bin/systemd-machine-id-setup
It is unclear whether this is really an issue. If all your source is open and you have verified that all programs either don’t use the value or use it in the approved manner ( sd_id128_get_machine_app_specific or equivalent ) then maybe it’s OK.
Needless to say that it may not be safe to regenerate the value on the fly if software is actually using the value.
Reading the man page, it may be viable to force /etc/machine-id to be an empty read-only file. Then you will automatically get a new random value at each boot.
An uniquely-identifiable-to-the-phone value is a privacy issue – one librem5 shouldn’t be able to tell which one it is, because that will become an identifier for its users set.
Since you necrod the topic …
It may be unavoidable having a machine-id but you could at least re-randomise.
On desktop (all as root) I manually tried
cd /etc
mv machine-id machine-id.save
touch machine-id
(reboot)
cd /etc
chmod u-w machine-id
and that seemed to work correctly. (You can see the activation of systemd-machine-id-commit.service in the syslog at startup - and you can see obviously that the machine-id changed, with no apparent connection between old and new value. I imagine that the values are just UUIDs of the “random” version.)
You could presumably create a service called localstartstop (or whatever) and put the first 3 commands in the “stop” script and the remaining 2 commands in the “start” script – but I haven’t tried that yet. That would re-randomise on each boot.
Just learned about this the other day. Alarming in light of recent news about the Peter Stokes bust with help from the Microsoft GDID.
Corollary therefore … if you are using IPv6 and, within that, you are using stable-privacy then don’t do what I am suggesting (re-randomise on each boot).
Huh, well crappy thing about systemd is that apparently if you change the machine-id, you have to reboot. It’s tied into too many things.
Between this and Debian replacing GNU Coreutils with uutils enrustification garbage, I really need to figure out a way to get PureBoot working with a non systemd distro.
True. That really doesn’t have anything to do with systemd though.
Another way of putting it is … if you have a machine-id and applications use it in arbitrary ways as a unique persistent identifier then you cannot guarantee the correct operation of all applications if the machine-id changes without a reboot. (It’s worse than that. If you have network-based applications where a bunch of computers communicate and cooperate then a change of machine-id on one computer might require a restart of the application on all computers.)
In fact though, it’s the other way round. The only correct way of requesting a change of machine-id is via a reboot (as in my first post above). I mean sure you can just hack the /etc/machine-id file with a new value but there is a risk that it gets overwritten at shutdown and just goes back to what the value was previously (because you don’t control the timing of the “commit” to persistent storage).
I guess it comes back to a design question: If N applications all need the same or similar functionality … should it be centralised within the operating system in order to avoid reinvention of the wheel or should it be left to each application to implement in order to avoid worsening the privacy implications (in this scenario)?
And there’s the related question: if you leave it to each application to implement, will their implementations be even worse for privacy‽
It is arguable that /etc/machine-id should have been root-accessible only - so that non-privileged applications cannot directly read the machine-id and user applications are therefore forced to use an API to get the machine-id and the API can then force the use of an application-specific hashed machine-id (rather than the raw machine-id).
The statement there does not appear to match either my experience or the documentation.
If the file exists and is empty then it does not trigger the “first boot” logic. That’s why I did the commands shown above the way I did. An empty file triggers generation of a new machine-id but without triggering any other “first boot” logic.
That’s a worthwhile warning too. (Some people are messing around with renaming the journal directory to follow the change of machine-id, or similar, but I suspect that this doesn’t work very well.)
This highlights that this aspect of the design can make sense. A central computer can act as a store of journals for many different computers and they are cleanly separated with one directory for each remote computer (in addition to the computer’s own journal) and a remote computer will keep its journal unless its machine-id changes - and you can use journalctl --directory=... to select which computer’s journal to examine.
It just happens not to work well for a more common personal computer usage scenario if you want to rotate the machine-id.
