[bug#74597] Confirming problem

["Danny Milosavljevic" <dannym@scratchpost.org>]

Hi,

I have the same problem with Linux 6.11.11 and bluez 5.72.

I would like the fix to be in guix, but unfortunately it would cause
2455 packages (including erlang, gtk, gnome, gdm, qemu, qt, kde,
mate and enlightenment) that depend on bluez to rebuild (WTF!).

And I don't think there are a lot of Guix users using bluetooth.

So I should not just apply it to master as it is.

We could make a graft with just the patch[1]--even though it's not a
security patch. What do you all think? Make an exception here?

The cause was that the kernel reverted a bugfix. The bugfix would have
done a link type fixup (see below). But it was a userspace-visible change
(broke the interface guarantee between kernel and user space) and so
that's a no-no, and hence was reverted. So now someone else has to do
the bugfix in userspace--in this case bluez[1].

Reverted bugfix was[2]:

    If two Bluetooth devices both support BR/EDR and BLE, and also
    support Secure Connections, then they only need to pair once.
    The LTK generated during the LE pairing process may be converted
    into a BR/EDR link key for BR/EDR transport, and conversely, a
    link key generated during the BR/EDR SSP pairing process can be
    converted into an LTK for LE transport. Hence, the link type of
    the link key and LTK is not fixed, they can be either an LE LINK
    or an ACL LINK.

Because the keys are (and were) stored on disk, userspace will always
have to do this kind of sanity check anyway--so this patch[1] will
likely stay in bluez releases forever.

[1] <https://github.com/bluez/bluez/commit/366a8c522b648f47147de4852c5c030d69b916b3.patch>
[2] <https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.206>, search for "59b047bc98084f8af2c41483e4d68a5adf2fa7f7"