i'm trying to understand the implications of this statement from the documentation you linked:

This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network.

do you know the details on that?

Quoting more from the manpage:

The machine ID is usually generated from a random source during system installation or first boot and stays constant for all subsequent boots. Optionally, for stateless systems, it is generated during runtime during early boot if necessary.

We should make sure systemd is able to write to this during installation / first boot, but putting it into NixOS configuration sounds wrong.

For the special usecases where it's desired to set this via kernel cmdline, we already have the cmdline config option, but I wouldn't encourage further to set this.

This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network.

do you know the details on that?

I'm not aware of anything in systemd itself which relies on machine-id being secret (and I've looked for such a thing before).

Theoretically, putting machine-id in the kernel's cmdline is more exposure than the current situation (with /etc/machine-id on the FS) and I'll happily rewrite this to use environment.etc if that's preferred. The reason I set it through cmdline in the first place was so distinct machines with otherwise-identical config share more drvs (which is somewhat helpful in network-boot contexts etc.)

The machine ID is usually generated from a random source during system installation or first boot and stays constant for all subsequent boots. Optionally, for stateless systems, it is generated during runtime during early boot if necessary.

We should make sure systemd is able to write to this during installation / first boot, but putting it into NixOS configuration sounds wrong.

For the special usecases where it's desired to set this via kernel cmdline, we already have the cmdline config option, but I wouldn't encourage further to set this.

Are “impermanent” / root-on-tmpfs systems such a special usecase? I made the PR because someone asked me to upstream that option (which I wrote in my config monorepo some years ago) and it seems to be a common pitfall for impermanent systems.

It causes unexpected behavior with the journal, among other things: every boot gets a different machine-id so journalctl does not show previous boots by default, etc.

I set it through cmdline in the first place was so distinct machines with otherwise-identical config share more drvs (which is somewhat helpful in network-boot contexts etc.)

In the netboot scenario, can't you set / extend the kernel cmdline independently of the system closure?

That's what I used to do, in cases where I wanted to pass along the ipxe machine UUID to systemd. Similar things were also suggested to people asking for this to be added into CoreOS:
coreos/bugs#2166

Are “impermanent” / root-on-tmpfs systems such a special usecase?

If you don't want to have a new machine UUID on such systems, simply exclude this file from being wiped on every reboot.

Having a static value part of your system config is only a big footgun, having two machines with the same UUID. I don't think we should introduce this as a config option.

I set it through cmdline in the first place was so distinct machines with otherwise-identical config share more drvs (which is somewhat helpful in network-boot contexts etc.)

In the netboot scenario, can't you set / extend the kernel cmdline independently of the system closure?

Yes, there are other options too in the netboot scenario specifically.

Having a static value part of your system config is only a big footgun, having two machines with the same UUID. I don't think we should introduce this as a config option.

I don't see how it's more of a footgun than the plethora of extent options for setting a MAC address (worse, those have the potential for breaking the entire LAN the devices sit on) but I won't insist either; close as “won't fix” if the maintainers do not wish to provide such an option.

I'm also not a big fan of this change.

https://systemd.io/BUILDING_IMAGES/ also recommends people not setting machine-id when building images.

Also there are multiple ways for people to set this. (kernel command line vs environment.etc). I think people should just use environment.etc or the kernel command line if they want to mess with this.

After speaking about @flokli on this,

@nbraud I would recommend the way forward is to document it in the NixOS manual about which situations may require to use a persistent machine-id you pass on the command line and to provide a simple snippet to do so.
More involved situations should probably have an out-of-tree NixOS module to perform the regex testing if needed.

document it in the NixOS manual about which situations may require to use a persistent machine-id you pass on the command line and to provide a simple snippet to do so.

@RaitoBezarius What part of the manual do you think this should go in?

document it in the NixOS manual about which situations may require to use a persistent machine-id you pass on the command line and to provide a simple snippet to do so.

@RaitoBezarius What part of the manual do you think this should go in?

This could go in https://nixos.org/manual/nixos/stable/#ch-running under its own section potentially.