[Pkg-utopia-maintainers] Bug#1040915: bookworm-pu: package dbus/1.14.8-2~deb12u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian.org at packages.debian.org
Usertags: pu
X-Debbugs-Cc: dbus at packages.debian.org, debian-boot at 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.