Package: release.debian.org Severity: normal Tags: bookworm User: release.debian....@packages.debian.org Usertags: pu X-Debbugs-Cc: d...@packages.debian.org, debian-b...@lists.debian.org Control: affects -1 + src:dbus
[ Reason ] https://bugs.debian.org/1040790 [ Impact ] A regression in bookworm's dbus packaging led to /etc/machine-id and /var/lib/dbus/machine-id having different contents in fresh installations of bookworm or later. The machine ID is an opaque hex string analogous to a MAC address, intended to identify the machine in contexts where the hostname would traditionally have been used, but avoiding the risk that a sysadmin setting an aesthetically appealing hostname will result in non-uniqueness (either the same hostname on more than one concurrently used installation, or the same installation having more than one hostname over time). Some packages that rely on this interface try /etc/machine-id first and fall back to /var/lib/dbus/machine-id if it doesn't exist, while others do the opposite, so this bug leads to those packages disagreeing on what the machine ID is, and therefore potentially behaving as though they are running on two different machines with a shared (NFS) home directory. The full user-visible impact of this is unknown: the machine ID is intentionally quite a general feature, so we cannot know all the things that might use it. pulseaudio, ibus, dbus-x11 and maybe others have autostart protocols that involve it, so non-uniqueness could result in unintentionally running two instances of the same service on the same machine. Conversely, GNOME and maybe others store per-machine data in the user's home directory (in particular, GNOME screen settings) keyed by the machine ID, so the apparent machine ID changing could result in apparent configuration data loss. [ Tests ] The majority of the changes are new automated test coverage. I can reproduce the problem with mmdebstrap, and I have confirmed that replacing packages from src:dbus with the proposed version resolves it. I have not attempted to provide the updated dbus to a d-i image and do an install from first principles. [ Risks ] Low-risk change, reverting unnecessary complexity in the postinst and returning to what we did in bullseye. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] All changes are part of resolving or testing #1040790. [ Other info ] dbus technically has a udeb, but it's essentially unused, and in any case dbus-udeb.postinst never had this bug (so it has not changed here). I have not attempted to retroactively fix the machine ID of existing installations: that would be much higher-risk and will require considerably more thought. It's entirely possible that the best approach to existing installations is to ignore the mismatch and hope that it doesn't cause any user-visible symptoms.
