👋 Hi folks, I noticed https://github.com/osquery/osquery/pull/8616 in the new release and wanted to make sure I understood the impact: • If there's a case where getting a hardware id previously transiently failed at first osquery startup (e.g. hitting one of the timeout cases) but the hardware id can be successfully read later on that device (e.g. maybe a system reboot resolved the issue?), any such device will immediately change UUID upon install of this new release instead of using the previously-cached generated UUID. • In the event of a hardware change like a motherboard swap, the device's UUID will now change to match the current UUID (whereas previously the existing UUID would have been kept stable for the remaining lifetime of the install) • Installs that are copied across different devices with their db intact will now change UUIDs rather than sharing the original UUID. And in fact, all existing cases of this already in the wild where the UUID was copied and does not match the current hardware UUID will immediately change UUID upon install of this new release.

This looks right, with the added context that this is only if the

host_identifier

flag is set to

uuid

, where we're attempting to make the identifier match the UUID provided by the platform. If you want a unique ID that won't change under any circumstances,

--host_identifier=instance

or

--host_identifier=specified_identifier

is the way to go.