On Thu, 15 Aug 2019 at 09:54:44 +0100, Ian Jackson wrote: > Do we have a list of all the things this is (or might be) used for ?
As I said, I don't think a comprehensive list is feasible without resorting to something like codesearch, because it's of similar scope to a list of reasons to use the hostname (as in gethostname(2)), and indeed some current uses of the hostname would probably be better to use the machine ID (if that's possible to do without breaking compatibility, which in some cases it won't be). I believe the original reasoning for the D-Bus machine ID (from which systemd took the idea) went something like this: - I need to do $something per-machine - but what if the user decides they don't like their current hostname (which after all is user-facing) and changes it to one that is more aesthetically appealing? then I won't be able to find the state that I previously stored in the home directory, X11 display or whatever is the shared resource - conversely, what if the hostname is not unique among the machines sharing the X11 display/home directory/other shared resource, because they all think they are called "debian" or "localhost" or similar? then they will overwrite each other's state so "like the hostname, but opaque" is quite a good mental model for it. The second point (hostname sometimes changing) was exacerbated by the tendency for some distros to pass a hostname received from DHCP to sethostname(), although I think (I hope) everyone has now decided that was a bad idea and stopped doing so. The dbus commit that switched from hostnames to machine IDs in the X11 autolaunch protocol appears to have been in 2006, which was before my first commit to dbus - I'm making an informed guess about former maintainers' motivations here, not stating why I made a decision. I cannot, now, change how dbus uses machine IDs without breaking backwards compatibility. Another precursor of the machine ID is gethostid(), but that's only 32 bits long, which is clearly not enough to be "unique among all UNIX systems in existence" as its man page claims. > I wonder if we should in Debian have a "sticky door" policy on the use > of machine-id, like we do for virtual packages: "please come to -devel > for a peer review". I can see the reasoning for suggesting this, but we don't ask for peer review for uses of other identifying properties like the hostname, MAC address, chassis serial number, etc., and I don't think it's realistic to expect the authors of upstream software to come to Debian seeking permission to use an OS interface. (In some cases the machine ID forms part of an upstream API or an interface between stored data and the software, from which Debian maintainers cannot diverge without breaking compatibility, so the upstream design is relevant here.) Also, this suggestion appears to be closing (or at least applying glue to) the door of a stable that has not contained horses for more than a decade. The concept of a machine UUID is far from new or innovative at this point. systemd's machine-id(5) now recommends using a HMAC of the machine ID with an application-specific key (reference implementation: sd_id128_get_machine_app_specific()), which is not something that the D-Bus maintainers thought of back in 2006, but with hindsight is an improvement over just having one form of the machine ID; but again, not everything can do this without it being an incompatible change. (If machine-id(5) already existed, but D-Bus didn't, and I was designing D-Bus now, then I'd probably be using sd_id128_get_machine_app_specific() or equivalent for the "is this peer on the same machine as me?" APIs in the D-Bus specification; but that isn't the order in which things happened.) smcv