Re: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code

[Johan Hedberg <johan.hedberg@gmail.com>]

Hi Waldek,

On Thu, Sep 02, 2010, Waldemar.Rymarkiewicz@tieto.com wrote:
> I've completed more tests on the patches and didn't faced any problems
> do far.  Legacy paring, ssp, sec mode 3, refresh existing keys and
> security upgrading have finished with success. I did the tests for
> bluez as initiator and again when bluez was an acceptor. All tests
> were done against different controllers CSR (1.1, 2.0, 2.1), Broadcom
> (2.0, 2.1), ST-Ericsson (2.1). I also tried different combinations of
> the controllers in the same use case.
> 
> So, I'm pretty sure that it will not introduce any regression. 

Ok, that's good to hear.

> Aditionally, we plan to bring this to the UPF and it would be
> appreciated if  also other would have that possibility for regression
> testing.

I'll be at the UPF too, so this might be possible.

> If it comes to interaction with the agent I would do this in a
> seperate patch which will contain a new property when 16 digit pin
> code is required.

That's fine.

> I attached slightly updated patches.

Thanks. However, the kernel patch and new ioctl will need comments at
least from Marcel. Once we add an ioctl we're stuck with it for quite
some time and have to maintain it, no matter what kind of newer/better
kernel-userspace interfaces we come up with. So the choice of accepting
a new ioctl isn't so easy.

One thing that you'd definitely need to fix in your patches is to keep
at least the same level of support that the current BlueZ has with
kernels that don't have the new ioctl. Right now your patch would make
legacy pairing fail in such cases which is not acceptable. Only with a
major version change (5.x) would it be possible to consider requiring a
newer kernel version in order to have essential functionality in place.

With all this in mind I'd still prefer it if we postpone the feature
addition until the point where we have a more flexible kernel-userspace
API in place and most of the security logic and information on the
kernel side.

Johan