ASF subversion and git services commented on PROTON-862:

Commit 0f90a7e4c9cc5a1decd7f6896c16d9b8b0653316 in qpid-proton's branch 
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=0f90a7e ]

PROTON-909: Rearrange the test code to create the Cyrus SASL configuration
- Make the Cyrus SASL configuration global for all the testing
- This fixes test failures against earlier versions of the Cyrus library
- The bug this fixes relates to PROTON-862

> Proton using Cyrus SASL library is problematic because the library has global 
> state
> -----------------------------------------------------------------------------------
>                 Key: PROTON-862
>                 URL: https://issues.apache.org/jira/browse/PROTON-862
>             Project: Qpid Proton
>          Issue Type: Bug
>    Affects Versions: 0.10
>            Reporter: Andrew Stitcher
> The Cyrus SASL library is not 100% suitable for use in other libraries 
> because it has global state and needs to be globally initialised before use 
> as either a SASL client or SASL server. One requirement for this global 
> initialisation seems to be to load the mechanism plugins.
> This global state is problematic because we cannot dictate what the linked in 
> application and other libraries may do with Cyrus SASL themselves.
> In particular we currently use the sasl_server_init() call to set the 
> basename for the config file that is used for the SASL settings. It is 
> possible to work around this by passing in NULL instead of a name and so not 
> changing whatever the application may have set. However we will then need to 
> set the Cyrus SASL options "manually" by implementing the SASL_CB_GETOPT 
> callback which returns the options set in the config file, so that we don't 
> need Cyrus to do it for us.
> Even so we would still have to be setting the global callbacks to NULL in our 
> initialisation, as there is no way to make Cyrus ignore the global callback 
> initialisation - this implies that for correct interop no library (and 
> probably no application either) can ever set these global callbacks, as they 
> will have no way to ensure that some random library loaded in doesn't reset 
> them!
> Another (perhaps better) alternative would be to port Proton to use another 
> SASL library, which better respects being used in a library and has no global 
> state. A good example of this would be libgsasl. However its API is 
> significantly more complex to use, largely because it doesn't do the user 
> authentication part itself and requires the application or dependant library 
> to do it. So at this point this route would involve significant extra work, 
> although might be long term more maintainable.

This message was sent by Atlassian JIRA

Reply via email to