Re: git: a28ccb32bf56 - main - machine-id: generate a compact version of the uuid

On Mar 4, 2023, at 06:32, Tijl Coosemans <tijl@FreeBSD.org> wrote:
> 
> On Fri, 3 Mar 2023 10:36:20 -0800 Mark Millard <marklmi@yahoo.com> wrote:
>> What are the properties for the content of /etc/hostid
>> in FreeBSD? Where are they documented?
>> 
>> /etc/machine-id has strong property guarnatee
>> requirements in linux and dbus (which linux indicates
>> it has adopted requirements from):
>> 
>> https://man7.org/linux/man-pages/man5/machine-id.5.html
>> 
>> reports:
>> 
>> QUOTE
>> The machine ID does not change based on local or network
>> configuration or when hardware is replaced. Due to this and its
>> greater length, it is a more useful replacement for the
>> gethostid(3) call that POSIX specifies.
>> 
>> This machine ID adheres to the same format and logic as the D-Bus
>> machine ID.
>> END QUOTE
> 
> /etc/hostid is written once.  It does not change with network or
> hardware changes.
> 
>> https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html reports:
>> ( used via dbus-uuidgen --ensure=/etc/machine-id as one way
>> to get a linux-comaptibile /etc/machine-id for at least
>> some types of contexts )
>> 
>> QUOTE
>> The important properties of the machine UUID are that 1) it remains
>> unchanged until the next reboot and 2) it is different for any two
>> running instances of the OS kernel. That is, if two processes see
>> the same UUID, they should also see the same shared memory, UNIX
>> domain sockets, local X displays, localhost.localdomain resolution,
>> process IDs, and so forth
>> END QUOTE
>> 
>> 
>> Does /etc/hostid generated the normal way in FreeBSD have such
>> properties? (How do I look that up?)
> 
> Yes.  It's `kenv smbios.system.uuid` if that's available and generated
> by uuidgen otherwise.  The code is in /etc/rc.d/hostid and
> /etc/rc.d/hostid_save.

I probably also should have quoted the below for completeness:

QUOTE
Also, don't make it the same on two different systems; it needs to be
different anytime there are two different kernels running.
END QUOTE

There are implications for some virtual environments.

>> Returning to:
>> 
>> https://man7.org/linux/man-pages/man5/machine-id.5.html
>> 
>> QUOTE
>> 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.
>> END QUOTE
>> 
>> Is that at least recommended for handling FreeBSD's /etc/hostid
>> content?
> 
> No, the file is not documented at all, but this is a recommendation on
> how to use the file not a restriction on the content like the other
> quotes so this isn't an impediment to using the same ID in
> /etc/machine-id.

That presumes that what FreeBSD does with /etc/hostid content
keeps the content confidential by default, such as using hashing
to avoid there being a way to "retrieve the original machine ID".
(It may well, but that is not documented.) Otherwise following
the recommendation would be an impossibility for /etc/hostid
content.

>> Is FreeBSD going to document /etc/machine-id content properties
>> in a similar manor?
>> 
>> 
>> If FreeBSD ends up with a /etc/machine-id that does not have
>> the properties and recommended principles of use, it would
>> appear that the /etc/machine-id path would be highly misleading
>> and, so, inappropriate.

Thanks for the notes.

===
Mark Millard
marklmi at yahoo.com