Re: Proposed SASL changes (API and functional)

2015-03-03 Thread Ken Giusti
- Original Message - > From: "Gordon Sim" > To: us...@qpid.apache.org > Cc: proton@qpid.apache.org > Sent: Monday, March 2, 2015 2:30:28 PM > Subject: Re: Proposed SASL changes (API and functional) > > On 02/24/2015 08:48 PM, Andrew Stitcher wrote: > &

Re: Proposed SASL changes (API and functional)

2015-03-02 Thread Robbie Gemmell
On 2 March 2015 at 19:30, Gordon Sim wrote: > On 02/24/2015 08:48 PM, Andrew Stitcher wrote: >> >> In a short while when people have had enough time to absorb the proposal >> and comment I will post a code review of the actual code changes. As >> there are substantial API changes I'd like to get t

Re: Proposed SASL changes (API and functional)

2015-03-02 Thread Gordon Sim
On 02/24/2015 08:48 PM, Andrew Stitcher wrote: In a short while when people have had enough time to absorb the proposal and comment I will post a code review of the actual code changes. As there are substantial API changes I'd like to get this in for 0.9 because we were intending to stabilise the

Re: Proposed SASL changes (API and functional)

2015-03-02 Thread Robbie Gemmell
On 27 February 2015 at 11:56, Robbie Gemmell wrote: > On 26 February 2015 at 17:52, Andrew Stitcher wrote: >> On Thu, 2015-02-26 at 12:28 +, Robbie Gemmell wrote: >>> ... >>> I'm going to post my comments here and on the wiki, as I dont think >>> many (except maybe you) will actually see them

Re: Proposed SASL changes (API and functional)

2015-02-27 Thread Robbie Gemmell
On 26 February 2015 at 17:52, Andrew Stitcher wrote: > On Thu, 2015-02-26 at 12:28 +, Robbie Gemmell wrote: >> ... >> I'm going to post my comments here and on the wiki, as I dont think >> many (except maybe you) will actually see them on the wiki ;) > > Thank you for the excellent feedback. I

Re: Proposed SASL changes (API and functional)

2015-02-26 Thread Rafael Schloming
This is from Andrew's wiki comment. Sorry to paste it back to the list, but I'm having some difficulty commenting there: > >1. Setters with no getters >Philosophically I don't agree that you need to make all properties >read/write. I see no particular reason to make these properties re

Re: Proposed SASL changes (API and functional)

2015-02-26 Thread Alan Conway
On Wed, 2015-02-25 at 13:45 -0500, Andrew Stitcher wrote: > On Tue, 2015-02-24 at 15:48 -0500, Andrew Stitcher wrote: > > ... > > If you are at all interested please go and look at the proposal and > > comment on it there. > > Thank you very much to Alan and Jakub for commenting on my proposal. >

Re: Proposed SASL changes (API and functional)

2015-02-26 Thread Andrew Stitcher
On Thu, 2015-02-26 at 12:28 +, Robbie Gemmell wrote: > ... > I'm going to post my comments here and on the wiki, as I dont think > many (except maybe you) will actually see them on the wiki ;) Thank you for the excellent feedback. I'm going to answer on the wiki - as it'll save me from cutting

Re: Proposed SASL changes (API and functional)

2015-02-26 Thread Jakub Scholz
On Wed, Feb 25, 2015 at 7:45 PM, Andrew Stitcher wrote: > If it is ok with them I will copy the comments over there: > Alan, Jakub? > Sorry, I missed the wiki part. Feel free to copy my comment there if you want.

Re: Proposed SASL changes (API and functional)

2015-02-26 Thread Robbie Gemmell
On 25 February 2015 at 18:40, Andrew Stitcher wrote: > On Wed, 2015-02-25 at 10:27 +0100, Jakub Scholz wrote: >> ... >> But I find this part a bit dangerous: >> "Classically in protocols where SASL was not optional the way to avoid >> double authentication was to use the EXTERNAL SASL mechanism. W

Re: Proposed SASL changes (API and functional)

2015-02-25 Thread Andrew Stitcher
On Tue, 2015-02-24 at 15:48 -0500, Andrew Stitcher wrote: > ... > If you are at all interested please go and look at the proposal and > comment on it there. Thank you very much to Alan and Jakub for commenting on my proposal. The reason I asked people to comment over on the wiki is that it is ver

Re: Proposed SASL changes (API and functional)

2015-02-25 Thread Andrew Stitcher
On Wed, 2015-02-25 at 10:27 +0100, Jakub Scholz wrote: > ... > But I find this part a bit dangerous: > "Classically in protocols where SASL was not optional the way to avoid > double authentication was to use the EXTERNAL SASL mechanism. With AMQP, > SASL is optional, so if SSL is used for client a

Re: Proposed SASL changes (API and functional)

2015-02-25 Thread Andrew Stitcher
On Wed, 2015-02-25 at 10:46 -0500, Alan Conway wrote: > ... > One ignorant question: Qpid has a min/max "Security Strength Factor" for > encryption rather than a binary enable/disable. Is that relevant here? (Hardly an ignorant question!) You make a very good point, and this design may indeed be a

Re: Proposed SASL changes (API and functional)

2015-02-25 Thread Alan Conway
On Tue, 2015-02-24 at 15:48 -0500, Andrew Stitcher wrote: > As many of you know I've been working on implementing a SASL AMQP > protocol layer that does more than PLAIN and ANONYMOUS for proton-c. > > I'm currently in at a point where the work is reasonably functional > (with some gaps) > > I've

Re: Proposed SASL changes (API and functional)

2015-02-25 Thread Jakub Scholz
Hi Andrew, I'm definitely not a Proton expert, so please excuse me if I missed something. But I find this part a bit dangerous: "Classically in protocols where SASL was not optional the way to avoid double authentication was to use the EXTERNAL SASL mechanism. With AMQP, SASL is optional, so if S

Proposed SASL changes (API and functional)

2015-02-24 Thread Andrew Stitcher
As many of you know I've been working on implementing a SASL AMQP protocol layer that does more than PLAIN and ANONYMOUS for proton-c. I'm currently in at a point where the work is reasonably functional (with some gaps) I've put together a fairly comprehensive account of this work on the Apache w