autopair legacy devices

[cschramm]

Follow-up to #2167

It turns out that BlueZ' autopair does not really make a PIN database obsolete, opposed to what I assumed in #1614.

When BlueZ receives a PIN code request, it invokes callbacks to find one only if the pairing got initiated locally. That is the case if a blueman user uses "Pair". If "Connect" is used to connect to an unpaired device, the pairing is actually triggered by an incoming HCI event so that the autopair plugin does not get used.

The reason for that is security. When BlueZ determines a PIN to use, instead of RequestPinCode it invokes DisplayPinCode if the user needs to know it or even just uses the code if its a fixed one. If it would do that on incoming pairing requests, it would automatically accept the initiating devices (not a problem for a random PIN code for a keyboard as the device does not know it, but a huge problem if a fixed PIN code like 0000 is chosen).

gnome-bluetooth adds another layer of default PINs on top that seems completely redundant for outgoing pairing requests but also works for incoming ones. BlueZ always forwards PIN code requests for incoming ones with RequestPinCode and gnome-bluetooth tries to find a match in its database no matter which side initiated the pairing. Instead of just responding to BlueZ' request with the determined code, it first awaits user confirmation on remote initiated pairing attempts.

I filed bluez/bluez#637 for discussion as I'd love to see this getting improved on the bluetoothd layer (otherwise the autopair plugins seems rather useless), but the other option is to (re-)implement a proper autopair solution in blueman...

[infirit]

Yesterday I checked how plasma/bluedevil handles this. Remote pairing is the same as blueman, the user is prompted to provide a pin. When it's initiated locally thought their wizard it does a local pair so the pin is provided by the plugin. The difference is we allow users to connect to unpaired devices and from my testing bluedevil always does an explicit local pair (at least for the legacy pairing keyboards I tried).

Maybe for 2.4 we remove "Generic connect" and always do an explicit local pair. Or we don't allow this for legacypairing devices?

[cschramm]

we remove "Generic connect" and always do an explicit local pair

You still need "generic connect" for paired devices and the situation is probably exactly the same for specific services (network and serial), but yes, we could enforce or even implicitly trigger a pairing attempt before providing / executing any connection attempt to still rely on the autoconnect plugin. The thing is just... devices may provide services without pairing, so I'm not sure how valid that is. Also, the DualShock 3 controller is an example where you even cannot successfully pair with local initiation if I get it right.