[BUG] Add validation for Bluetooth MAC address format

[cachebag]

Describe the bug
Unlike WiFi PSK and WireGuard keys, Bluetooth bdaddr format isn't validated before connection attempts.

[pluiee]

Hi, currently working on this issue. I've implemented validate_bluetooth_address, but trying to figure out the best way to apply it.

In a conservative manner, I can apply validation to populate_bluez_info, BluetoothDevice::new, and BluetoothIdentity::new, all three functions that receive bdaddr as an argument. The last two will return Result<Self, ConnectionError> instead of Self if things are done this way, requiring some code changes.

Another option would be adding the validation only within populate_bluez_info. This option also makes sense because all BluetoothDevice::new calls rely on the results of populate_bluez_info, and all BluetoothIdentity::new calls will rely on BluetoothDevices. This approach might be vulnerable to future changes where dependencies are broken, but has simpler diffs.

I've also considered introducing newtype patterns to parse instead of validate. (e.g. BluetoothAddress(String), Ipv4Address(String), ...) It can make things more robust, but it's a very heavy change affecting all domains so I guess this can be listed as a future work if acceptable.

Would be happy to hear your thoughts!

[cachebag]

@pluiee Sorry for the delay!

I'd suggest a middle path...

We can add validation to BluetoothIdentity::new - This is the user-facing entry point where external/untrusted input comes in. This should return Result<Self, ConnectionError>. Then, we can add validation to populate_bluez_info. It would be more defensive for D-Bus data. This already returns Result, so it's a minimal change.

I'd say skip validation in BluetoothDevice::new; Its bdaddr always comes from populate_bluez_info in practice (see device.rs:149-157), so validating again would be redundant.

This gives us the safety benefits while keeping the diff manageable. BluetoothDevice::new can stay infallible since it's only called internally with already-validated data.

On the newtype pattern: Agreed that it's a heavier lift. Let's save that for a follow-up issue - it would be a nice architectural improvement but isn't necessary for this bug fix. Feel free to file an issue for that.

[pluiee]

@cachebag
Great! I'll open a PR later, applying validations to BluetoothIdentity and populate_bluez_info.