'Machine ID' underspecified?

[Thomas Kluyver]

On Mon, 7 Dec 2020, at 12:33, Simon McVittie wrote:
> 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".

Aha, I had overlooked that. I've been able to implement most of the basics just based on the spec and playing around with it interactively (I think I had one previous question about serial numbers). This question arose in Filipe's dbus-objects project, which builds higher level server features on top of my code.

> 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.

Thanks. So I think that can be summarised as: D-Bus implementations on Unix should try to read the machine ID from /var/lib/dbus/machine-id and /etc/machine-id (see also systemd machine-id). If both exist, they are expected to have the same contents, and if they differ, the spec does not define which takes precedence (the reference implementation prefers /var/lib/dbus/machine-id, but sd-bus does not).

If we wrote the /var/lib path in the spec, configuring the reference implementation to look in a different prefix would strictly make it non-spec-compliant, albeit in a way that would rarely matter (it will copy /etc/machine-id by default). Is that acceptable?

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

Got it :-)

> > Should this be described in the spec?
> 
> Sure, why not. Please send a merge request.

Great, will do!

> D-Bus over TCP has no integrity or confidentiality protection and has led to
> a 1.4 million vehicle recall[1] (presumably rather expensive)

Ouch, that must have been a bad day at Chrysler!

Thomas