From nobody Sat Mar 04 14:32:54 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PTS4B1QVlz3w5Sv; Sat, 4 Mar 2023 14:32:58 +0000 (UTC) (envelope-from tijl@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PTS4B0vZLz3D4g; Sat, 4 Mar 2023 14:32:58 +0000 (UTC) (envelope-from tijl@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677940378; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N6PeDknoxDgm1KsItHXC9riaV+qSWVUb5iob43UKbgg=; b=o2yTyu+IliIGEVl0ImhevWghbuG7G8dwq7kbv0gXF5d7b0KugjWuj6vhJXaT9F8D4ElsNb MXqqs4pePmLcLK1/1IGgR3NBnDJKLxkWEatj1ZB34lYrtLAGWboUQIxy5MXf5YiyQHejAu z80o8jFSGxLzd705TudVoUFBRBCL6USjFp89qAcayncoVTKyag5cK4OlcjPeSIDDsHr97g KRVGWJVOihoALWb4fgkwwCHvS+8g4/IY4zxS8hHq7UN9NawtHhj0+NbYj+45Fq/HhsTdZp U1fRNPD13P00XGJnaQoOdghuEPvLHXlVVLWcD7EDMmLOlxI6bTyLqgg6zRW52Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677940378; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N6PeDknoxDgm1KsItHXC9riaV+qSWVUb5iob43UKbgg=; b=VZKIw3GViYQStJmafTmkRqM2hl/KEAPpuB8dxg+bMHZEZGfJexYHJYyjkOGYI2riBsmCMh oG5ldducUX3x4OZL1FXPXTVSukCO7YyATnGQFrx9kFygxNlpFo/mRFGm6RSf9NQiP2g7DV CvGK2kClCIK+ZTPyx6zTl36ZAOdr5S6ksfmm4wy9R1MPU548en/x+cB/v6HSl9TEPeeWlG E63r3HhifxyV21F6pEo7tY/2FMqH4fdjm7mEYgCwHAqbr4fClO9gwMsyeeAqb7K+WN/2D7 Q/PjJ+CAZdM4ce8riyJVRzUDa9OlUfXfQrWMgM+BuVIYG16WAz4pn2n2QhmxEQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1677940378; a=rsa-sha256; cv=none; b=Va4NFT67fmsRGmGyRU16UOOtgEO5kH6jm+qhac0m0Hsn7h3IxdMNR8TzbOV5s98w+yl9bk 5WYWABl+iIecWY/o5K+EqwMhgLA4LOdPrAvWeaq5sYTsHg3AhfZauCIQYq+Tye4vBm+dNZ 7UZdvdVCwq8ZWvA6vmfZdG7weO18AS4QDSOoZl51WAC0a1rLr/hLMYgHRf5DuSxL3ng9uT h4uaklHrB2N8eIAitE2XliOxc4QFuMekqjll80bjFw4H9T5AObbrBacei4JbJsHyI7m3o9 tyUkTzgILO9Di6d+XY9ihUD8Q+gHeet/X41CHyJzJet7bcaqnygUh72KGiwyhA== Received: from hal.tijl.coosemans.org (unknown [IPv6:2a02:a03f:894b:4700:c041:70fd:a74e:2f53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: tijl) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PTS491PKsz1R06; Sat, 4 Mar 2023 14:32:57 +0000 (UTC) (envelope-from tijl@FreeBSD.org) Date: Sat, 4 Mar 2023 15:32:54 +0100 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Mark Millard Cc: Mike Karels , dev-commits-src-main@freebsd.org, "bapt@freebsd.org" , FreeBSD-STABLE Mailing List , Current FreeBSD Subject: Re: git: a28ccb32bf56 - main - machine-id: generate a compact version of the uuid Message-ID: <20230304153254.077542bd@hal.tijl.coosemans.org> In-Reply-To: <6227093D-3D45-4300-97B9-2F2D76C083BE@yahoo.com> References: <6227093D-3D45-4300-97B9-2F2D76C083BE.ref@yahoo.com> <6227093D-3D45-4300-97B9-2F2D76C083BE@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On Fri, 3 Mar 2023 10:36:20 -0800 Mark Millard 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. > 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. > 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.