linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bastien Nocera <hadess@hadess.net>
To: Szymon Janc <szymon.janc@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH 2/2 v3] sixaxis: Ask user whether cable configuration should be allowed
Date: Fri, 24 Jul 2015 13:06:00 +0200	[thread overview]
Message-ID: <1437735960.2863.20.camel@hadess.net> (raw)
In-Reply-To: <359424171.AW1qIKcMiD@athlon>

On Fri, 2015-07-24 at 00:33 +0200, Szymon Janc wrote:
> Hi Bastien,
> 
> On Tuesday 07 July 2015 16:14:25 Bastien Nocera wrote:
> > Previously, users doing cable configuration of Sixaxis PS3 
> > controllers
> > would only get asked whether a device was allowed to connect to the
> > computer when switching it to Bluetooth mode: unplugging it, and
> > pressing the PS button.
> > 
> > Instead, we should ask the user straight away, through the agent,
> > whether the pad should be allowed to connect.
> > 
> > This makes it easier to setup those devices, while keeping 
> > security.
> 
> Wouldn't this confuse user so that he may think device is already 
> connected 
> over BT?

No, because either:
- you don't want to pair the device with your computer, which is
impossible to do right now, and you can now do if you don't have an
agent, or reject the association
- you do want to be able to use it via Bluetooth, and we can have the
association happen in one go, instead of being 2 separate actions.

>  Also what would happen if user remove this from usb before 
> confirming?

I didn't implement this, but we should cancel the existing
authentication request indeed.

>  And if PS button is pressed then, second authorization request for 
> same UUID would be send?

It wouldn't do anything, as there's already an auth request in flux.

> Since this change plugin behavior in end user visible way this needs 
> to be 
> carefully thought out. It looks like people have different 
> requirements for 
> sixaxis security...

This is actually more secure than what came before, and it's also far
more predictable. It's the same security as before, but requires an
agent to be available when the device is plugged in.

>  so maybe it should have a sort of policy settings in 
> config file? Opinions?

What would the other policy be? I don't see a difference between the
current security behaviour, and the one set out in this patch.

      reply	other threads:[~2015-07-24 11:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-07 14:14 [PATCH 2/2 v3] sixaxis: Ask user whether cable configuration should be allowed Bastien Nocera
2015-07-23 22:33 ` Szymon Janc
2015-07-24 11:06   ` Bastien Nocera [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1437735960.2863.20.camel@hadess.net \
    --to=hadess@hadess.net \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=szymon.janc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).