Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
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
Reply to: