www/chromium: Patch location of machine-id

[jrm]

Summary

The location of machine-id is set to /etc/machine-id (systemd-ism), so
change it to what is expected on FreeBSD, /var/lib/dbus/machine-id.

PR: 247175
Submitted by: Samy Mahmoudi <[e-mail]>
Reported by:

[cem]

Reading https://www.freedesktop.org/software/systemd/man/machine-id.html , it seems like we should either write /etc/machine-id directly, in place of or addition to the /var location; OR, symlink /etc/machine-id to the /var location. Patching software to look in a non-canonical location is going to be more error-prone than conforming.

[jrm]

In D26085#579078, @cem wrote:

Reading https://www.freedesktop.org/software/systemd/man/machine-id.html , it seems like we should either write /etc/machine-id directly, in place of or addition to the /var location; OR, symlink /etc/machine-id to the /var location. Patching software to look in a non-canonical location is going to be more error-prone than conforming.

$PREFIX/bin/dbus-uuidgen from devel/dbus writes machine-id to /var/lib/dbus. If we make a change to the location of machine-id it likely makes most sense to do it there. Copying @koobs @tijl who made the changes to the location (last in r431187).

[tijl]

I guess you could let dbus create a symlink, but why does Chromium need this id? The comment indicates it is transmitted. Isn't that a privacy violation?

[cem]

In D26085#579194, @tijl wrote:

why does Chromium need this id? The comment indicates it is transmitted. Isn't that a privacy violation?

The comment also reads:

which is why we hash it first … before transmitting

Hashes are one-way functions. It's certainly true hashing is not always sufficient to make an input private; for example, very short keys like phone numbers or short passwords can be reversed by just brute-forcing the key space. Machineids are 128-bit uuids, though. Brute-forcing the entire 2^128 space is not feasible.

In D26085#579136, @jrm wrote:

$PREFIX/bin/dbus-uuidgen from devel/dbus writes machine-id to /var/lib/dbus. If we make a change to the location of machine-id it likely makes most sense to do it there. Copying @koobs @tijl who made the changes to the location (last in r431187).

It seems like systemd adopted the dbus file and "promoted" it into /etc, if I'm reading the description right. So applications may look in both locations, depending on when they were written and against what OS. I guess I think we should write both, or symlink one to the other.

[jrm]

From the document that Conrad linked to, it sounds like Chromium is doing what is intended. What they are using the unique id for is another question.

This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. 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. The sd_id128_get_machine_app_specific(3) API provides an implementation of such an algorithm.

It sounds like the link is intended to be from /etc/machine-id pointing to /var/lib/dbus/.

The simple configuration file format of /etc/machine-id originates in the /var/lib/dbus/machine-id file introduced by D-Bus. In fact, this latter file might be a symlink to /etc/machine-id.

[jrm]

We now have an rc script that generates /var/db/machine-id and an /etc/machine-id symlink is created pointing to /var/db/machine-id.