Do we, even as a "Unix app," really have to strictly follow the machine-id(5) guidelines?
This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network.
It is unclear to which degree the identifier should be kept "confidential." How much confidentiality does it merit?
1. Is it used to derive some authentication credentials, or a private key? If so, it should *not* be world-readable in the first place. This contradicts with the current state of affairs (/etc/machine-id is r--r--r--). All the hashing stuff should be done by some daemon, if it's really needed.
2. Is it merely used to identify a particular *physical* system, and the OS installation is not intended to be movable? If so, it is not any more confidential than, say, a hardware UUID.
3. Is it merely used to identify a particular *virtual* system, where the OS installation may roam? If so, it may have different privacy and confidentiality requirements than hardware UUID. Still, there are a lot of other ways to fingerprint the OS installation identity (e.g., the dev/ino or mtime of certain system directories), and it is not clear that /etc/machine-id passthrough is at the frontier of the privacy threat posed by Wine.
If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one.
This is a reasonable take, regardless of confidentiality. However, Wine has long ago already decided to use /etc/machine-id as-is, for better or worse. We wouldn't want to break backward compatibility unless for a very good reason.
---
The supposed main motivation behind the confidentiality of /etc/machine-id seems to be that it is not easily renewable by the user, since it's intended to be persistent. However, note that machine-id(5) says it's still okay to *derive* a persistent identifier from it.
The reasonable conclusion here is that the user should be allowed to renew application-specific persistent identifiers due to security or privacy concerns, without changing the global /etc/machine-id and breaking things that literally require its persistent (e.g., cluster management, journal logs).
However, if the user had to care about privacy or security (e.g., server deployments), they should be running Wine inside a VM or container anyway. Also, desktop/client (non-server) users could probably also change /etc/machine-id without much side effects.
-
Jinoh Kang (＠iamahuman)