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 <astitc...@apache.org> 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: users-unsubscr...@qpid.apache.org >> For additional commands, e-mail: users-h...@qpid.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
