[
https://issues.apache.org/jira/browse/PROTON-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14588574#comment-14588574
]
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
(v6.3.4#6332)
