Seeking opinions: Change to proton-c SASL mechanisms semantics

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Seeking opinions: Change to proton-c SASL mechanisms semantics

astitcher
There is a long standing pain point with using cyrus SASL: If you have
Kerberos set up in your environment; are authenticated with Kerberos;
and have the GSSAPI mechanism installed; but you are not using the
ambient Kerberos credential for AMQP.

In this case (which is common, at least in Red Hat internal
environments) A Cyrus SASL client will pick Kerberos as the mechanism
even though the server doens't have a ticket and the authentication
fails immediately without any further SASL negotiation (this might be a
bug in Cyrus, but I don't think it's ever going to be fixed if so).
This is recorded as a JIRA [1] which has been open for a couple of
years.

The solution to this problem is not to offer/accept the GSSAPI or GSS-
SPNEGO mechanisms by default. This should give the least surprising
default experience.

I have a PR [1] avalable which does just this. It works like this:

If the user has explicitly set the SASL mechanisms that are allowed
then these are all used on both server and client. If no allowed
mechanisms are set it filters out the problematic mechanisms from both
the mechanisms offered by the server and the mechanisms that are
considered by the client.

I think this is simple and straigtforward, however it changes the
mechanism selection semantic significantly if you actually want
Kerberos.

For instance there is actually *no way* to return to the current
semantic of offering/selecting all possible mechanisms if you don't
already know what they are (there is no way to query the available
mechanisms in the pn_sasl API).

Is this important? If it is, there are a number of possible solutions -
all involving some extra API complexity. I'd prefer to avoid this if
possible, as I believe that simpler APIs are just easier to
use/understand as long as they allow you to do what is needed.

1. The simplest way to return to the previous semantic would be to have
a new API named something pn_sasl_set_allow_problematic_mechs() - in
line with the existing pn_sasl_set_allow_insecure_mechs(). This would
return the semantic to the existing one.

2. Special case selecting "" - the empty string as the allowed
mechanisms. Currently using pn_sasl_allowed_mechs to "" is useless as
it will not allow *any* mechs to be selected. So this could be used as
a (hacky) way to return to the previous semantic without any extra APIs
being introduced and without affecting existing code as no one could be
doing this currently. Personnally I don't favour this idea as I prefer
something expicit, and this would be strange implicit behaviour.

3. Introduce a concept of excluded mechanisms. There'd be a new API
called something like pn_sasl_excluded_mechs() which would set the
excluded mech list. It would default to "GSSAPI GSS-SPNEGO", but you
could set it to "" if you wanted the previous behaviour. This would
also allow the possiblility of excluding other mechanisms of you wanted
that for whatever reason. On the whole I don't really like this idea as
it complicates the API and semantics for little apparent gain and
raises the question of the detailed interaction of the excluded/allowed
mechanisms.

My current thinking is that I should merge the PR [2] and see if anyone
is affected by the change, if so then I prefer solution 1. What do
other people think?

Andrew

[1] https://issues.apache.org/jira/browse/PROTON-1354
[2] https://github.com/apache/qpid-proton/pull/148

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Gordon Sim
On 15/06/18 16:35, Andrew Stitcher wrote:

> There is a long standing pain point with using cyrus SASL: If you have
> Kerberos set up in your environment; are authenticated with Kerberos;
> and have the GSSAPI mechanism installed; but you are not using the
> ambient Kerberos credential for AMQP.
>
> In this case (which is common, at least in Red Hat internal
> environments) A Cyrus SASL client will pick Kerberos as the mechanism
> even though the server doens't have a ticket and the authentication
> fails immediately without any further SASL negotiation (this might be a
> bug in Cyrus, but I don't think it's ever going to be fixed if so).
> This is recorded as a JIRA [1] which has been open for a couple of
> years.

You can of course also specify a mech list in the cyrus sasl config.

> The solution to this problem is not to offer/accept the GSSAPI or GSS-
> SPNEGO mechanisms by default. This should give the least surprising
> default experience.
>
> I have a PR [1] avalable which does just this. It works like this:
>
> If the user has explicitly set the SASL mechanisms that are allowed
> then these are all used on both server and client. If no allowed
> mechanisms are set it filters out the problematic mechanisms from both
> the mechanisms offered by the server and the mechanisms that are
> considered by the client.
>
> I think this is simple and straigtforward, however it changes the
> mechanism selection semantic significantly if you actually want
> Kerberos.

To me it, this solves one usability issue at the expense of creating
another. The argument for it would be that the issue solved affects more
people than the issue created and I have no evidence to the contrary.

My own inclination would be to leave things as they are without clear
evidence that this is a change users would prefer, but I wouldn't oppose
a different view.

> For instance there is actually *no way* to return to the current
> semantic of offering/selecting all possible mechanisms if you don't
> already know what they are (there is no way to query the available
> mechanisms in the pn_sasl API).
>
> Is this important? If it is, there are a number of possible solutions -
> all involving some extra API complexity. I'd prefer to avoid this if
> possible, as I believe that simpler APIs are just easier to
> use/understand as long as they allow you to do what is needed.
>
> 1. The simplest way to return to the previous semantic would be to have
> a new API named something pn_sasl_set_allow_problematic_mechs() - in
> line with the existing pn_sasl_set_allow_insecure_mechs(). This would
> return the semantic to the existing one.

I think 'problematic' is the wrong term to use there (seems somewhat
libelous!).

> 2. Special case selecting "" - the empty string as the allowed
> mechanisms. Currently using pn_sasl_allowed_mechs to "" is useless as
> it will not allow *any* mechs to be selected. So this could be used as
> a (hacky) way to return to the previous semantic without any extra APIs
> being introduced and without affecting existing code as no one could be
> doing this currently. Personnally I don't favour this idea as I prefer
> something expicit, and this would be strange implicit behaviour.
>
> 3. Introduce a concept of excluded mechanisms. There'd be a new API
> called something like pn_sasl_excluded_mechs() which would set the
> excluded mech list. It would default to "GSSAPI GSS-SPNEGO", but you
> could set it to "" if you wanted the previous behaviour. This would
> also allow the possiblility of excluding other mechanisms of you wanted
> that for whatever reason. On the whole I don't really like this idea as
> it complicates the API and semantics for little apparent gain and
> raises the question of the detailed interaction of the excluded/allowed
> mechanisms.
>
> My current thinking is that I should merge the PR [2] and see if anyone
> is affected by the change, if so then I prefer solution 1. What do
> other people think?
>
> Andrew
>
> [1] https://issues.apache.org/jira/browse/PROTON-1354
> [2] https://github.com/apache/qpid-proton/pull/148
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

astitcher
On Fri, 2018-06-15 at 16:52 +0100, Gordon Sim wrote:
> ...
> > This is recorded as a JIRA [1] which has been open for a couple of
> > years.
>
> You can of course also specify a mech list in the cyrus sasl config.

True, but this is fairly complex - involving a configuration file used
for no other purpose and setting up an environment variable.

> > I think this is simple and straigtforward, however it changes the
> > mechanism selection semantic significantly if you actually want
> > Kerberos.
>
> To me it, this solves one usability issue at the expense of creating
> another. The argument for it would be that the issue solved affects
> more
> people than the issue created and I have no evidence to the contrary.

What do you perceive the new usability issue to be specifically?

> My own inclination would be to leave things as they are without
> clear
> evidence that this is a change users would prefer, but I wouldn't
> oppose
> a different view.

There have been a number of users that have been tripped up by this, as
 well as the developers at Red Hat frequently. I didn't do a search on
the lists yet.

> ...
>
> I think 'problematic' is the wrong term to use there (seems somewhat
> libelous!).

I know I'm going into bike shedding territory here (!) but do you have
another word that you think is less 'libelous'? IMO every word that
captures the problem is likely to be equally libelous!

Andrew

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Gordon Sim
On 15/06/18 18:02, Andrew Stitcher wrote:
> On Fri, 2018-06-15 at 16:52 +0100, Gordon Sim wrote:
>> ...
>>> This is recorded as a JIRA [1] which has been open for a couple of
>>> years.
>>
>> You can of course also specify a mech list in the cyrus sasl config.
>
> True, but this is fairly complex - involving a configuration file used
> for no other purpose and setting up an environment variable.

If you want to cyrus sasl to actually authenticate then you need the
conf file anyway I think, e.g. to point at a sasldb or some other source
of user information.

>>> I think this is simple and straigtforward, however it changes the
>>> mechanism selection semantic significantly if you actually want
>>> Kerberos.
>>
>> To me it, this solves one usability issue at the expense of creating
>> another. The argument for it would be that the issue solved affects
>> more
>> people than the issue created and I have no evidence to the contrary.
>
> What do you perceive the new usability issue to be specifically?

That the normal mechanism for configuring cyrus sasl does not work as
expected due to being overridden for a specific case in the proton library.

>> My own inclination would be to leave things as they are without
>> clear
>> evidence that this is a change users would prefer, but I wouldn't
>> oppose
>> a different view.
>
> There have been a number of users that have been tripped up by this, as
>   well as the developers at Red Hat frequently. I didn't do a search on
> the lists yet.

Is this when developing custom servers? Or with specific existing servers?

>> ...
>>
>> I think 'problematic' is the wrong term to use there (seems somewhat
>> libelous!).
>
> I know I'm going into bike shedding territory here (!) but do you have
> another word that you think is less 'libelous'? IMO every word that
> captures the problem is likely to be equally libelous!

I would suggest something explicit like enable_gss_mechs or something. I
don't think there is anything wrong with the mechanism itself.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Gordon Sim
On 15/06/18 18:32, Gordon Sim wrote:

> On 15/06/18 18:02, Andrew Stitcher wrote:
>> On Fri, 2018-06-15 at 16:52 +0100, Gordon Sim wrote:
>>> ...
>>>> This is recorded as a JIRA [1] which has been open for a couple of
>>>> years.
>>>
>>> You can of course also specify a mech list in the cyrus sasl config.
>>
>> True, but this is fairly complex - involving a configuration file used
>> for no other purpose and setting up an environment variable.
>
> If you want to cyrus sasl to actually authenticate then you need the
> conf file anyway I think, e.g. to point at a sasldb or some other source
> of user information.

Maybe another solution would be to install a default config file when
installing proton, with a mechlist that excludes GSSAPI (e.g. just
ANONYMOUS and EXTERNAL).


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

aconway.rh
In reply to this post by astitcher
On Fri, Jun 15, 2018 at 1:02 PM, Andrew Stitcher <[hidden email]>
wrote:

>
> > ...
> >
> > I think 'problematic' is the wrong term to use there (seems somewhat
> > libelous!).
>

I know I'm going into bike shedding territory here (!) but do you have
> another word that you think is less 'libelous'? IMO every word that
> captures the problem is likely to be equally libelous!
>
> I prefer the "pn_sasl_excluded_mechs()" approach. It's inoffensively
worded, and it gives the user the power to define the set of mechs that
they find "problematic" if they don't agree with our default set.
Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

astitcher
In reply to this post by Gordon Sim
Having read this email I understand that we are talking somewhat at
cross purposes. I should have explained better!

My major concern is the default *client* behaviour. In this case you
don't have the config file, but you will get tripped up by mysterious
failures if you have the GSSAPI mech installed.

If you are implementing a server then you will have a config file, but
equally you will know if you are inplementing kerberos so setting it up
specificially isn't usually a problem either.

Andrew

On Fri, 2018-06-15 at 18:32 +0100, Gordon Sim wrote:

> On 15/06/18 18:02, Andrew Stitcher wrote:
> > On Fri, 2018-06-15 at 16:52 +0100, Gordon Sim wrote:
> > > ...
> > > > This is recorded as a JIRA [1] which has been open for a couple
> > > > of
> > > > years.
> > >
> > > You can of course also specify a mech list in the cyrus sasl
> > > config.
> >
> > True, but this is fairly complex - involving a configuration file
> > used
> > for no other purpose and setting up an environment variable.
>
> If you want to cyrus sasl to actually authenticate then you need the
> conf file anyway I think, e.g. to point at a sasldb or some other
> source
> of user information.
>
> > > > I think this is simple and straigtforward, however it changes
> > > > the
> > > > mechanism selection semantic significantly if you actually want
> > > > Kerberos.
> > >
> > > To me it, this solves one usability issue at the expense of
> > > creating
> > > another. The argument for it would be that the issue solved
> > > affects
> > > more
> > > people than the issue created and I have no evidence to the
> > > contrary.
> >
> > What do you perceive the new usability issue to be specifically?
>
> That the normal mechanism for configuring cyrus sasl does not work
> as
> expected due to being overridden for a specific case in the proton
> library.
>
> > > My own inclination would be to leave things as they are without
> > > clear
> > > evidence that this is a change users would prefer, but I wouldn't
> > > oppose
> > > a different view.
> >
> > There have been a number of users that have been tripped up by
> > this, as
> >   well as the developers at Red Hat frequently. I didn't do a
> > search on
> > the lists yet.
>
> Is this when developing custom servers? Or with specific existing
> servers?
>
> > > ...
> > >
> > > I think 'problematic' is the wrong term to use there (seems
> > > somewhat
> > > libelous!).
> >
> > I know I'm going into bike shedding territory here (!) but do you
> > have
> > another word that you think is less 'libelous'? IMO every word that
> > captures the problem is likely to be equally libelous!
>
> I would suggest something explicit like enable_gss_mechs or
> something. I
> don't think there is anything wrong with the mechanism itself.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Robbie Gemmell
Administrator
Right. I also dont think anything needs done on the server side
personally, it seems fair they should be configuring exactly what they
want to offer.

I think its reasonable that clients dont attempt to do GSSAPI by
default unless it has been enabled in some way, since it requires
specific external configuration.

For the JMS client we made it so it doesn't attempt to select GSSAPI
by default, it requires you configure the enabled mechanisms via the
URI and include it there before it will.

Robbie

On 15 June 2018 at 19:44, Andrew Stitcher <[hidden email]> wrote:

> Having read this email I understand that we are talking somewhat at
> cross purposes. I should have explained better!
>
> My major concern is the default *client* behaviour. In this case you
> don't have the config file, but you will get tripped up by mysterious
> failures if you have the GSSAPI mech installed.
>
> If you are implementing a server then you will have a config file, but
> equally you will know if you are inplementing kerberos so setting it up
> specificially isn't usually a problem either.
>
> Andrew
>
> On Fri, 2018-06-15 at 18:32 +0100, Gordon Sim wrote:
>> On 15/06/18 18:02, Andrew Stitcher wrote:
>> > On Fri, 2018-06-15 at 16:52 +0100, Gordon Sim wrote:
>> > > ...
>> > > > This is recorded as a JIRA [1] which has been open for a couple
>> > > > of
>> > > > years.
>> > >
>> > > You can of course also specify a mech list in the cyrus sasl
>> > > config.
>> >
>> > True, but this is fairly complex - involving a configuration file
>> > used
>> > for no other purpose and setting up an environment variable.
>>
>> If you want to cyrus sasl to actually authenticate then you need the
>> conf file anyway I think, e.g. to point at a sasldb or some other
>> source
>> of user information.
>>
>> > > > I think this is simple and straigtforward, however it changes
>> > > > the
>> > > > mechanism selection semantic significantly if you actually want
>> > > > Kerberos.
>> > >
>> > > To me it, this solves one usability issue at the expense of
>> > > creating
>> > > another. The argument for it would be that the issue solved
>> > > affects
>> > > more
>> > > people than the issue created and I have no evidence to the
>> > > contrary.
>> >
>> > What do you perceive the new usability issue to be specifically?
>>
>> That the normal mechanism for configuring cyrus sasl does not work
>> as
>> expected due to being overridden for a specific case in the proton
>> library.
>>
>> > > My own inclination would be to leave things as they are without
>> > > clear
>> > > evidence that this is a change users would prefer, but I wouldn't
>> > > oppose
>> > > a different view.
>> >
>> > There have been a number of users that have been tripped up by
>> > this, as
>> >   well as the developers at Red Hat frequently. I didn't do a
>> > search on
>> > the lists yet.
>>
>> Is this when developing custom servers? Or with specific existing
>> servers?
>>
>> > > ...
>> > >
>> > > I think 'problematic' is the wrong term to use there (seems
>> > > somewhat
>> > > libelous!).
>> >
>> > I know I'm going into bike shedding territory here (!) but do you
>> > have
>> > another word that you think is less 'libelous'? IMO every word that
>> > captures the problem is likely to be equally libelous!
>>
>> I would suggest something explicit like enable_gss_mechs or
>> something. I
>> don't think there is anything wrong with the mechanism itself.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Gordon Sim
In reply to this post by astitcher
On 15/06/18 19:44, Andrew Stitcher wrote:
> Having read this email I understand that we are talking somewhat at
> cross purposes. I should have explained better!
>
> My major concern is the default *client* behaviour. In this case you
> don't have the config file, but you will get tripped up by mysterious
> failures if you have the GSSAPI mech installed.

Only if the server you are connecting to offers it as a mechanism.

Both qdrouterd and qpidd have default sasl config files that specify a
default mech list that doesn't include GSSAPI. The java broker requires
you to explicitly enable GSSAPI. Is there another commonly used server
that has GSSAPI on by default?


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Justin Ross-3
In reply to this post by Robbie Gemmell
On Fri, Jun 15, 2018 at 12:25 PM Robbie Gemmell <[hidden email]>
wrote:

> I think its reasonable that clients dont attempt to do GSSAPI by
> default unless it has been enabled in some way, since it requires
> specific external configuration.
>

This is the case that interests me.  I've been tripped up by this more than
once.  I consider it a user gotcha.  Even if you look at the trace, you
have to know that GSSAPI requires extra steps

I acknowledge that this change could introduce another kind of surprising
behavior, but in my view it's a narrower one.

Another way to solve it would be some sort of user-visible warning.  I'm
not sure what the options are here.
Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Gordon Sim
On 15/06/18 20:40, Justin Ross wrote:

> On Fri, Jun 15, 2018 at 12:25 PM Robbie Gemmell <[hidden email]>
> wrote:
>
>> I think its reasonable that clients dont attempt to do GSSAPI by
>> default unless it has been enabled in some way, since it requires
>> specific external configuration.
>>
>
> This is the case that interests me.  I've been tripped up by this more than
> once.

Against which server?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Gordon Sim
In reply to this post by astitcher
On 15/06/18 19:44, Andrew Stitcher wrote:
> My major concern is the default *client* behaviour. In this case you
> don't have the config file, but you will get tripped up by mysterious
> failures if you have the GSSAPI mech installed.

Your patch affects server behaviour also though. Even if GSSAPI is in
the mech_list in the cyrus config, it will not be offered. This affects
the router for example, it would need to now enable the excluded
mechanisms or else user would be unable to use GSSAPI with it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Justin Ross-3
In reply to this post by Gordon Sim
I can't quite remember.  I've just now checked all the full-fledged servers
I use regularly (qpidd, qdrouterd, artemis), and they all restrict to an
explicit list of mechs that excludes GSSAPI, as you suggest.

It's probably something I've recently run into only with test servers and
peer-to-peer client examples.  Cyrus SASL makes it somewhat painful to
configure them, so they usually don't have the explicit list.

Anyway, I agree that mitigates the problem considerably.  I know Andrew
happened to have this problem recently, which is why he raised the PR and
the topic.

On Fri, Jun 15, 2018 at 12:46 PM Gordon Sim <[hidden email]> wrote:

> On 15/06/18 20:40, Justin Ross wrote:
> > On Fri, Jun 15, 2018 at 12:25 PM Robbie Gemmell <
> [hidden email]>
> > wrote:
> >
> >> I think its reasonable that clients dont attempt to do GSSAPI by
> >> default unless it has been enabled in some way, since it requires
> >> specific external configuration.
> >>
> >
> > This is the case that interests me.  I've been tripped up by this more
> than
> > once.
>
> Against which server?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Gordon Sim
On 15/06/18 20:58, Justin Ross wrote:
> I can't quite remember.  I've just now checked all the full-fledged servers
> I use regularly (qpidd, qdrouterd, artemis), and they all restrict to an
> explicit list of mechs that excludes GSSAPI, as you suggest.
>
> It's probably something I've recently run into only with test servers and
> peer-to-peer client examples.  Cyrus SASL makes it somewhat painful to
> configure them, so they usually don't have the explicit list.

Yes, it is certainly an issue with the non-intermediated examples. The
README for the python covers this briefly and a default conf file is
included:
https://git1-us-west.apache.org/repos/asf/qpid-proton/repo?p=qpid-proton.git;a=blob;f=python/examples/proton-server.conf;h=6d236fe60808d0f2eb711070e28531056c00c9a0;hb=HEAD

As I suggested earlier, perhaps one solution to that would be to install
a similar conf file with proton. This would not alter the configuration
mechanism for those familiar with cyrus sasl, but would avoid the issue
'out of the box' in much the same way as qpidd and qdrouterd do.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

astitcher
In reply to this post by astitcher
Thanks everyone for their thoughts:

I've considered the feedback, especially Gordon's point that the server
mechanisms are already configured using the SASL configuration file
which you need in any case to set up the authenticatino db.

I think the issue is still enough of a speed bump to new developers
that I've decided to go ahead and make this a purely client side
filter. In this case there won't be any confusion over proton opaquely
changing the mech list from what the SASL config file lists. I've gone
with with the simplest no extra API option - this can certainly change
is it turns out to be a problem.

The new PR is in the same place [1] and I'll merge this soon unless
there are serious objections.

Andrew

[1] https://github.com/apache/qpid-proton/pull/148
Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Gordon Sim
On 19/06/18 15:39, Andrew Stitcher wrote:
> Thanks everyone for their thoughts:
>
> I've considered the feedback, especially Gordon's point that the server
> mechanisms are already configured using the SASL configuration file
> which you need in any case to set up the authenticatino db.
>
> I think the issue is still enough of a speed bump to new developers
> that I've decided to go ahead and make this a purely client side
> filter.

Can you elaborate a little on that? Would installing a default sasl
config along with the library not address those cases?

> In this case there won't be any confusion over proton opaquely
> changing the mech list from what the SASL config file lists. I've gone
> with with the simplest no extra API option - this can certainly change
> is it turns out to be a problem.
>
> The new PR is in the same place [1] and I'll merge this soon unless
> there are serious objections.

I think it is the wrong solution.

I don't imagine it will affect all that many people though, so if you
are determined I won't stand in the way.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

aconway.rh
A related (not identical) issue is
https://issues.apache.org/jira/browse/DISPATCH-244
Andrews fix will fix that problem as well as the failures discussed here.
Installing config files will not, nor will it help with developers trying
out examples in a source build etc.

I agree that this is not an issue for a properly configured production
system, and there are easy workarounds (make sure your laptop has a dotted
name, always specify mechs=ANONYMOUS for examples and tests etc.) but given
the way the problem shows maddeningly in some situations but usually not,
it could easily frustrate developers to the point that they throw proton
away before they find the workarounds. It took me 2 weeks to figure out
that dispatch tests would run 10x faster if I turned off my VPN, and more
weeks to realize I needed to use saslMechs=ANONYMOUS everywhere. I think
another month before Chuck discovered  that calling your machine
"bob.localdomain" instead of "bob" also fixed the problem. For developers
who initially don't care about security and expect things to Just Work with
default config, I think this issue may be losing us developers.

Cheers,
Alan.


On Tue, Jun 19, 2018 at 11:01 AM, Gordon Sim <[hidden email]> wrote:

> On 19/06/18 15:39, Andrew Stitcher wrote:
>
>> Thanks everyone for their thoughts:
>>
>> I've considered the feedback, especially Gordon's point that the server
>> mechanisms are already configured using the SASL configuration file
>> which you need in any case to set up the authenticatino db.
>>
>> I think the issue is still enough of a speed bump to new developers
>> that I've decided to go ahead and make this a purely client side
>> filter.
>>
>
> Can you elaborate a little on that? Would installing a default sasl config
> along with the library not address those cases?
>
> In this case there won't be any confusion over proton opaquely
>> changing the mech list from what the SASL config file lists. I've gone
>> with with the simplest no extra API option - this can certainly change
>> is it turns out to be a problem.
>>
>> The new PR is in the same place [1] and I'll merge this soon unless
>> there are serious objections.
>>
>
> I think it is the wrong solution.
>
> I don't imagine it will affect all that many people though, so if you are
> determined I won't stand in the way.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Gordon Sim
On 19/06/18 16:44, Alan Conway wrote:
> A related (not identical) issue is
> https://issues.apache.org/jira/browse/DISPATCH-244
> Andrews fix will fix that problem as well as the failures discussed here.

Would setting the sasl configuration of the router for the tests not help?

> Installing config files will not, nor will it help with developers trying
> out examples in a source build etc.

True, though you could fix that by having the examples set the sasl
mechanisms explicitly.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

aconway.rh
On Tue, Jun 19, 2018 at 11:55 AM, Gordon Sim <[hidden email]> wrote:

> On 19/06/18 16:44, Alan Conway wrote:
>
>> A related (not identical) issue is
>> https://issues.apache.org/jira/browse/DISPATCH-244
>> Andrews fix will fix that problem as well as the failures discussed here.
>>
>
> Would setting the sasl configuration of the router for the tests not help?
>

Yes, I believe most of them have been set by now.


> Installing config files will not, nor will it help with developers trying
>> out examples in a source build etc.
>>
>
> True, though you could fix that by having the examples set the sasl
> mechanisms explicitly.
>

True again, but I would prefer to avoid mysterious failures by default,
rather than via extra code/configuration that .developers must remember,
even if we do modify every example to use mechs=ANONYMOUS. The fact that
*we* didn't know we needed to use ANONYMOUS in all tests and examples until
the problem bit us makes me worry that others will fall down the same
rabbit-hole.
Reply | Threaded
Open this post in threaded view
|

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Gordon Sim
On 19/06/18 17:56, Alan Conway wrote:

> On Tue, Jun 19, 2018 at 11:55 AM, Gordon Sim <[hidden email]> wrote:
>
>> On 19/06/18 16:44, Alan Conway wrote:
>>
>>> A related (not identical) issue is
>>> https://issues.apache.org/jira/browse/DISPATCH-244
>>> Andrews fix will fix that problem as well as the failures discussed here.
>>>
>>
>> Would setting the sasl configuration of the router for the tests not help?
>>
>
> Yes, I believe most of them have been set by now.
>
>
>> Installing config files will not, nor will it help with developers trying
>>> out examples in a source build etc.
>>>
>>
>> True, though you could fix that by having the examples set the sasl
>> mechanisms explicitly.
>>
>
> True again, but I would prefer to avoid mysterious failures by default,

I would argue that a better way to do that is to be explicit about how
servers are configured. After all what if some other mechanism plugin
turns out to have unanticipated side effects.

> rather than via extra code/configuration that .developers must remember,

I think a sasl server *should* be configured, and I think the failure to
do so is what actually causes the problems.

> even if we do modify every example to use mechs=ANONYMOUS. The fact that
> *we* didn't know we needed to use ANONYMOUS in all tests and examples until
> the problem bit us makes me worry that others will fall down the same
> rabbit-hole.

Again, I think a better solution there would be either to modify the
server examples to explicitly set the mechanisms or to improve the
documentation to explain the need to configure sasl better (as I say,
the python examples README does this, but we could find ways to
emphasise it if it is indeed tripping lots of people up).

To me the problem is one of server misconfiguration and it would be
better to try and tackle that directly rather than impose a change that
mysteriously eliminates server offered mechanisms on all users.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12