[ 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)