'Machine ID' underspecified?

[Simon McVittie]

On Sat, 05 Dec 2020 at 15:34:31 +0000, Thomas Kluyver wrote:
> libdbus handles calls to this method automatically, so if you're
> using that, you're covered. However, the spec doesn't define how other
> implementations can get a machine ID. It seems clear from the description
> that implementations can't just come up with their own way to make a
> suitable ID - they need to match the reference implementation (assuming
> they're talking on the standard message buses).

Yes. The spec does say explicitly that "any attempt to reimplement D-Bus
will probably require looking at the reference implementation and/or
asking questions on the D-Bus mailing list about intended behavior".

A typical use of the machine ID is that gnome-settings-daemon stores
screen layouts per-machine, so that if you share the same home directory
between two PCs with different screens attached, it will remember a
separate layout for each one. In that use, it's only necessary for a small
number of closely interoperating processes to agree on the machine ID.

If two ecosystems of packages on the same machine disagree about how to
get the machine ID (for example, packages that use libdbus and packages
that use GDBus might disagree), then the worst that will happen is that
they think the bus is being shared by two machines; they might avoid
using fd-passing and fall back to less efficient in-band communication
through the bus, for example.

> I looked into the code for the reference implementation. On Unix, it gets the ID from a compile-time configurable file (/var/lib/dbus/machine-id on my system) with a hardcoded fallback to /etc/machine-id:
> 
> https://gitlab.freedesktop.org/dbus/dbus/-/blob/2ef39181cfe1443c349500740855bf86f195f540/dbus/dbus-sysdeps-unix.c#L4257-4274

Some non-reference implementations such as systemd's sd-bus unconditionally
use /etc/machine-id, or use /etc/machine-id in preference to
/var/lib/dbus/machine-id. I would say that best-practice for "freedesktop"
OS vendors is that /etc/machine-id and /var/lib/dbus/machine-id should both
exist with the same contents, perhaps by making one a symlink to the other;
and D-Bus implementations should read one of those files with a fallback to
the other.

/etc/machine-id is a generalization of the D-Bus machine ID for non-D-Bus
uses. It originated in systemd (see systemd's machine-id(5),
<https://www.freedesktop.org/software/systemd/man/machine-id.html>) but
I would encourage non-systemd-based "freedesktop" OS distributions like
Devuan and *BSD to provide it too.

With hindsight, the reference implementation's use of a ${prefix}-relative
path for the machine ID is unwise: if you don't know ahead of time where
dbus was installed, it makes interoperability impossible. More generally,
a package that installs in a GNU-style configurable ${prefix} isn't really
compatible with providing a "filesystem API". However, in practice dbus is
nearly always an OS component installed into /usr, /var and /etc, so
assuming /var/lib/dbus/machine-id is nearly always correct.

systemd and dbus will both try to populate both /etc/machine-id and
/var/lib/dbus/machine-id with the same content, although if the two IDs
already exist with different content, at least dbus (probably systemd too)
will leave both intact.

> On Windows it appears to use a Windows API call GetCurrentHwProfileA to get a GUID representing the 'hardware profile', and reformat it into the UUID format D-Bus needs:
> 
> https://gitlab.freedesktop.org/dbus/dbus/-/blob/2ef39181cfe1443c349500740855bf86f195f540/dbus/dbus-sysdeps-win.c#L2820

I think the reformatting is essentially just removal of punctuation:
Windows GUID {12340001-4980-1920-6788-123456789012} becomes D-Bus machine
ID 12340001498019206788123456789012.

> Should this be described in the spec?

Sure, why not. Please send a merge request.

    smcv