Uploaded image for project: 'Qpid Proton'
  1. Qpid Proton
  2. PROTON-950

SASL PLAIN over cleartext should be supported

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 0.10
    • Fix Version/s: 0.10
    • Component/s: proton-c
    • Labels:
      None

      Description

      In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if the connection is encrypted (using SSL). This is a surprising change of behavior from earlier versions of Proton and it's arguable that a security policy like that should be left to the application using the Proton library.

        Activity

        Hide
        gemmellr Robbie Gemmell added a comment -

        This is marked fix-for 0.10. Is it a blocker?

        (I'd say yes personally)

        Show
        gemmellr Robbie Gemmell added a comment - This is marked fix-for 0.10. Is it a blocker? (I'd say yes personally)
        Hide
        tedross Ted Ross added a comment -

        That makes two of us. I've updated it accordingly.

        Show
        tedross Ted Ross added a comment - That makes two of us. I've updated it accordingly.
        Hide
        astitcher Andrew Stitcher added a comment -

        This can only be a change in behaviour for applications that are using the messenger library, as it is the only part of the Proton-c library that has the PLAIN mechanism built in before 0.10.

        My proposed change is to add an API to the SASL object allow_insecure_mechs(bool) which defaults to false for the underlying Proton-c library as used directly via the engine or event APIs. If this property is set true then it will allow plain to be used unencrypted.

        For the messenger APIs I will default to insecure mechs by default for 0.10, but note that this will be changed in 0.11 to a more secure setting in the 0.10 release notes and the messenger documentation.

        Show
        astitcher Andrew Stitcher added a comment - This can only be a change in behaviour for applications that are using the messenger library, as it is the only part of the Proton-c library that has the PLAIN mechanism built in before 0.10. My proposed change is to add an API to the SASL object allow_insecure_mechs(bool) which defaults to false for the underlying Proton-c library as used directly via the engine or event APIs. If this property is set true then it will allow plain to be used unencrypted. For the messenger APIs I will default to insecure mechs by default for 0.10, but note that this will be changed in 0.11 to a more secure setting in the 0.10 release notes and the messenger documentation.
        Hide
        gsim Gordon Sim added a comment -

        "This can only be a change in behaviour for applications that are using the messenger library, as it is the only part of the Proton-c library that has the PLAIN mechanism built in before 0.10." - Idon't think that is correct. The python 'reactive' api also supported plain previously but now only does so on ssl connections.

        Show
        gsim Gordon Sim added a comment - "This can only be a change in behaviour for applications that are using the messenger library, as it is the only part of the Proton-c library that has the PLAIN mechanism built in before 0.10." - Idon't think that is correct. The python 'reactive' api also supported plain previously but now only does so on ssl connections.
        Hide
        astitcher Andrew Stitcher added a comment -

        Did the 0.9 Python "Reactive" API code send the SASL frame manually in Python?

        There was no code previously in Proton-C which sent a PLAIN SASL init frame except in the messenger code.

        Show
        astitcher Andrew Stitcher added a comment - Did the 0.9 Python "Reactive" API code send the SASL frame manually in Python? There was no code previously in Proton-C which sent a PLAIN SASL init frame except in the messenger code.
        Hide
        gsim Gordon Sim added a comment -

        It set the chosen mechanism to be plain if a username and password were specified in the url (using the Sasl.plain() method).

        Show
        gsim Gordon Sim added a comment - It set the chosen mechanism to be plain if a username and password were specified in the url (using the Sasl.plain() method).
        Hide
        astitcher Andrew Stitcher added a comment - - edited

        [I don't understand - the previous code didn't implement any mechanisms except ANONYMOUS, how did PLAIN work?]

        Oh - I see, that (removed) method set the SASL INIT frame directly to a PLAIN mechanism frame.

        Show
        astitcher Andrew Stitcher added a comment - - edited [I don't understand - the previous code didn't implement any mechanisms except ANONYMOUS, how did PLAIN work?] Oh - I see, that (removed) method set the SASL INIT frame directly to a PLAIN mechanism frame.
        Hide
        astitcher Andrew Stitcher added a comment -

        Given that the 0.10 version of the Python reactive API should work correctly with any other SASL mech just by setting the user and password to the API I'm not sure that the potential accidental security loss is worth it for an such a new API.

        You can still use the allow_insecure_mechs SASL property to allow PLAIN in this case.

        However if you feel this is widely used I can change it in the same way as I'm proposing for the messenger API.

        Show
        astitcher Andrew Stitcher added a comment - Given that the 0.10 version of the Python reactive API should work correctly with any other SASL mech just by setting the user and password to the API I'm not sure that the potential accidental security loss is worth it for an such a new API. You can still use the allow_insecure_mechs SASL property to allow PLAIN in this case. However if you feel this is widely used I can change it in the same way as I'm proposing for the messenger API.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit c954cf3e4f35e79a6cd5832cc977d136c607a20b in qpid-proton's branch refs/heads/master from Andrew Stitcher
        [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c954cf3 ]

        PROTON-950: Allow PLAIN over clear text if you ask nicely

        Show
        jira-bot ASF subversion and git services added a comment - Commit c954cf3e4f35e79a6cd5832cc977d136c607a20b in qpid-proton's branch refs/heads/master from Andrew Stitcher [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c954cf3 ] PROTON-950 : Allow PLAIN over clear text if you ask nicely
        Hide
        gemmellr Robbie Gemmell added a comment -

        Andrew Stitcher is this done? Ted Ross, Gordon Sim does the change made satisfy things from your perspectives?

        Are there uses of the engine that also need updated to use this new API before the release, or are they being left only supporting plain over SSL?

        It would be good to close this out so we can proceed with the release, it appears to be the only blocker currently.

        Show
        gemmellr Robbie Gemmell added a comment - Andrew Stitcher is this done? Ted Ross , Gordon Sim does the change made satisfy things from your perspectives? Are there uses of the engine that also need updated to use this new API before the release, or are they being left only supporting plain over SSL? It would be good to close this out so we can proceed with the release, it appears to be the only blocker currently.
        Hide
        astitcher Andrew Stitcher added a comment -

        At this point I don't think master is blocked as you now can use PLAIN unencrypted if you need to.

        However I'm finding some valgrind issues with the CI tests on Ubuntu 12.04 when I add the code to default messenger to allowing PLAIN over unencrypted connections. I want to make sure the CI builds are clean before we release, so I'm investigating the valgrind issues.

        These issues seem to actually be in the version of cyrus SASL on the CI machine, but I want to be sure before adding in valgrind suppressions for them.

        Show
        astitcher Andrew Stitcher added a comment - At this point I don't think master is blocked as you now can use PLAIN unencrypted if you need to. However I'm finding some valgrind issues with the CI tests on Ubuntu 12.04 when I add the code to default messenger to allowing PLAIN over unencrypted connections. I want to make sure the CI builds are clean before we release, so I'm investigating the valgrind issues. These issues seem to actually be in the version of cyrus SASL on the CI machine, but I want to be sure before adding in valgrind suppressions for them.
        Hide
        gemmellr Robbie Gemmell added a comment -

        Can anyone clue me in on how you would enable the new transport flag client-side with the python reactive bits, to allow connecting to a server offering PLAIN without using SSL? I had a look but didn't see a way to do so. My interest is for new or existing users connecting to servers that e.g only support PLAIN (and possibly ANONYMOUS), such as ActiveMQ or some others, who are doing so without SSL.

        This all also makes me wonder if the default shouldn't be the other way round (particularly if there is actually no easy way to use the new transport option in some cases). I believe the engine allows ANONYMOUS and no-SASL-layer by default currently, so it seems strange that we would deny use of PLAIN in the same situtation. The argument for allowing ANONYMOUS was that it eased initial pickup by new developers, and that people will secure their production setups; it feels to me that essentially the same argument applies for PLAIN without SSL and that treating them differently is perhaps a bit inconsistent.

        Show
        gemmellr Robbie Gemmell added a comment - Can anyone clue me in on how you would enable the new transport flag client-side with the python reactive bits, to allow connecting to a server offering PLAIN without using SSL? I had a look but didn't see a way to do so. My interest is for new or existing users connecting to servers that e.g only support PLAIN (and possibly ANONYMOUS), such as ActiveMQ or some others, who are doing so without SSL. This all also makes me wonder if the default shouldn't be the other way round (particularly if there is actually no easy way to use the new transport option in some cases). I believe the engine allows ANONYMOUS and no-SASL-layer by default currently, so it seems strange that we would deny use of PLAIN in the same situtation. The argument for allowing ANONYMOUS was that it eased initial pickup by new developers, and that people will secure their production setups; it feels to me that essentially the same argument applies for PLAIN without SSL and that treating them differently is perhaps a bit inconsistent.
        Hide
        gsim Gordon Sim added a comment -

        I tried unsuccessfully to do this. It is awkward to get at the sasl object for a connection when using the reactor. In theory you can do so via the on_connection_bound method. However even doing so, and setting the new property to True, I was unable to connect using PLAIN over a non-ssl connection.

        Without making any changes, the behaviour also seems to have changed very recently. Previously when attempting to connect where only PLAIN was offered by the broker, an error would at least be logged to the effect that 'no worthy mechs' could be selected, and both sides would end up disconnected. Now there is no error at all and the reactive examples just hang.

        Show
        gsim Gordon Sim added a comment - I tried unsuccessfully to do this. It is awkward to get at the sasl object for a connection when using the reactor. In theory you can do so via the on_connection_bound method. However even doing so, and setting the new property to True, I was unable to connect using PLAIN over a non-ssl connection. Without making any changes, the behaviour also seems to have changed very recently. Previously when attempting to connect where only PLAIN was offered by the broker, an error would at least be logged to the effect that 'no worthy mechs' could be selected, and both sides would end up disconnected. Now there is no error at all and the reactive examples just hang.
        Hide
        astitcher Andrew Stitcher added a comment -

        Gordon Sim Could you bug report that last issue, because that isn't the intended behaviour - you should definitely get an error (and preferably the 'no worthy mechs' error too) if no matching mech could be found. If you can include some sort of reproducer I'll try to create a good test case from it and fix the probelm.

        Show
        astitcher Andrew Stitcher added a comment - Gordon Sim Could you bug report that last issue, because that isn't the intended behaviour - you should definitely get an error (and preferably the 'no worthy mechs' error too) if no matching mech could be found. If you can include some sort of reproducer I'll try to create a good test case from it and fix the probelm.
        Hide
        gsim Gordon Sim added a comment - - edited

        I can't seem to get the messenger examples to connect over non-ssl using PLAIN either...

        $ PN_TRACE_FRM=1 ./examples/c/messenger/send -a amqp://guest:guest@localhost/amq.fanout
        [0x162a700]:  -> SASL
        [0x162a700]:  <- SASL
        [0x162a700]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:PLAIN]
        [0x162a700]:  -> EOS
        
        Show
        gsim Gordon Sim added a comment - - edited I can't seem to get the messenger examples to connect over non-ssl using PLAIN either... $ PN_TRACE_FRM=1 ./examples/c/messenger/send -a amqp://guest:guest@localhost/amq.fanout [0x162a700]: -> SASL [0x162a700]: <- SASL [0x162a700]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:PLAIN] [0x162a700]: -> EOS
        Hide
        astitcher Andrew Stitcher added a comment -

        As to the first issue - it is possible that you didn't/can't set the property on the sasl object early enough, although this seems a little odd.

        The flag is examined when the SASL "Mechanisms" frame is received from the server end, at the point when the cyrus client structure is created. This should be well after the on_connection_bound event, although there may be a race going on here, if there is nothing to stop the client sending its SASL header before this setting happens.

        Show
        astitcher Andrew Stitcher added a comment - As to the first issue - it is possible that you didn't/can't set the property on the sasl object early enough, although this seems a little odd. The flag is examined when the SASL "Mechanisms" frame is received from the server end, at the point when the cyrus client structure is created. This should be well after the on_connection_bound event, although there may be a race going on here, if there is nothing to stop the client sending its SASL header before this setting happens.
        Hide
        astitcher Andrew Stitcher added a comment - - edited

        @gsim unless you've manually set the flag somehow for the messenger code this is expected as there is no code committed yet to do this automatically for messenger (else this repoort would already have been resolved!). All that is committed currently is the sasl level code for the option itself.
        [Edit: The hold up, is that adding that code to messenger causes valgrind errors on the Travis CI box which I can't exactly replicate. So I can't see whether it is safe just to suppress them]

        Show
        astitcher Andrew Stitcher added a comment - - edited @gsim unless you've manually set the flag somehow for the messenger code this is expected as there is no code committed yet to do this automatically for messenger (else this repoort would already have been resolved!). All that is committed currently is the sasl level code for the option itself. [Edit: The hold up, is that adding that code to messenger causes valgrind errors on the Travis CI box which I can't exactly replicate. So I can't see whether it is safe just to suppress them]
        Hide
        gsim Gordon Sim added a comment -

        Run eg. simple_send against direct_recv, or even just the messenger examples against a broker that only supports PLAIN.

        Show
        gsim Gordon Sim added a comment - Run eg. simple_send against direct_recv, or even just the messenger examples against a broker that only supports PLAIN.
        Hide
        astitcher Andrew Stitcher added a comment -

        There was a recent change to stop the SASL code from logging without any logging flags set. If you set PN_TRACE_DRV do you see any error output?

        Show
        astitcher Andrew Stitcher added a comment - There was a recent change to stop the SASL code from logging without any logging flags set. If you set PN_TRACE_DRV do you see any error output?
        Hide
        gsim Gordon Sim added a comment -

        What is the intended behaviour when cyrus is not available on the platform in question? Would PLAIN be allowed over a non-SSL connection in that case? To me that seems non-intuitive from the client's perspective.

        Show
        gsim Gordon Sim added a comment - What is the intended behaviour when cyrus is not available on the platform in question? Would PLAIN be allowed over a non-SSL connection in that case? To me that seems non-intuitive from the client's perspective.
        Hide
        gsim Gordon Sim added a comment -

        No, I didn't make any changes. I had just assumed from a comment above that the messenger code had been changed.

        Show
        gsim Gordon Sim added a comment - No, I didn't make any changes. I had just assumed from a comment above that the messenger code had been changed.
        Hide
        astitcher Andrew Stitcher added a comment -

        Also what are you doing when receiving PN_TRANSPORT_ERROR events? I did recently (think I'd) fix the SASL code to raise those errors correctly (at the correct time with the correct error code).

        Show
        astitcher Andrew Stitcher added a comment - Also what are you doing when receiving PN_TRANSPORT_ERROR events? I did recently (think I'd) fix the SASL code to raise those errors correctly (at the correct time with the correct error code).
        Hide
        gsim Gordon Sim added a comment -

        Yes, that does show up the error.

        Show
        gsim Gordon Sim added a comment - Yes, that does show up the error.
        Hide
        astitcher Andrew Stitcher added a comment - - edited

        With no Cyrus available the behaviour should be the same as with Cyrus. Just with fewer mechanisms available.

        The code paths are a little different though, so there could be different bugs in the two cases.

        Show
        astitcher Andrew Stitcher added a comment - - edited With no Cyrus available the behaviour should be the same as with Cyrus. Just with fewer mechanisms available. The code paths are a little different though, so there could be different bugs in the two cases.
        Hide
        gsim Gordon Sim added a comment -

        There is no special logic added for PN_TRANSPORT_ERROR events, but PN_TRANSPORT_CLOSED and PN_TRANSPORT_TAIL_CLOSED are handled. Previously this would result in the connection attempt failing and either reconnecting or exiting depending on settings (along with the error logged of course).

        Show
        gsim Gordon Sim added a comment - There is no special logic added for PN_TRANSPORT_ERROR events, but PN_TRANSPORT_CLOSED and PN_TRANSPORT_TAIL_CLOSED are handled. Previously this would result in the connection attempt failing and either reconnecting or exiting depending on settings (along with the error logged of course).
        Hide
        gsim Gordon Sim added a comment -

        That means that unless cyrus is available it would no longer be possible to authenticate as a given user unless SSL was used (since there would be no other mechanisms).

        Show
        gsim Gordon Sim added a comment - That means that unless cyrus is available it would no longer be possible to authenticate as a given user unless SSL was used (since there would be no other mechanisms).
        Hide
        astitcher Andrew Stitcher added a comment -

        It should be raising .._HEAD_CLOSED, .._TAIL_CLOSED and .._CLOSED.

        There could be something different about the reactive code from the test code though, are you not seeing any of the CLOSED events?

        Show
        astitcher Andrew Stitcher added a comment - It should be raising .._HEAD_CLOSED, .._TAIL_CLOSED and .._CLOSED. There could be something different about the reactive code from the test code though, are you not seeing any of the CLOSED events?
        Hide
        gemmellr Robbie Gemmell added a comment -

        I was about to reply questioning if that was the case, i.e. have we implemented ANONYMOUS, PLAIN, and EXTERNAL in the fallback and then disabled PLAIN by default?

        Show
        gemmellr Robbie Gemmell added a comment - I was about to reply questioning if that was the case, i.e. have we implemented ANONYMOUS, PLAIN, and EXTERNAL in the fallback and then disabled PLAIN by default?
        Hide
        gsim Gordon Sim added a comment -

        I've not debugged. The behaviour changed since about a week ago though.

        Show
        gsim Gordon Sim added a comment - I've not debugged. The behaviour changed since about a week ago though.
        Hide
        astitcher Andrew Stitcher added a comment -

        To be clear:

        • The client mechanisms available without Cyrus are ANONYMOUS, PLAIN and EXTERNAL
        • The server mechanisms are ANONYMOUS and EXTERNAL (no PLAIN because we have no way to request authentication of a user/password pair)
        • The default PLAIN behaviour is the same bith with and without Cyrus viz:
        • It is intuitive that the behaviour doesn't vary depending on the library build, but
        • By default without SSL you cannot authenticate a user without Cyrus.
        Show
        astitcher Andrew Stitcher added a comment - To be clear: The client mechanisms available without Cyrus are ANONYMOUS, PLAIN and EXTERNAL The server mechanisms are ANONYMOUS and EXTERNAL (no PLAIN because we have no way to request authentication of a user/password pair) The default PLAIN behaviour is the same bith with and without Cyrus viz: It is intuitive that the behaviour doesn't vary depending on the library build, but By default without SSL you cannot authenticate a user without Cyrus.
        Hide
        gemmellr Robbie Gemmell added a comment - - edited

        I'm increasingly feeling that this new option should be flipped so that PLAIN works by default and those that want to restrict it to SSL only can use it to do so. As mentioned earlier, it seems inconsistent to me to allow ANONYMOUS and no-SASL by default but deny PLAIN. It should only be used for lack of a better option, and yet we know there are times it is going to be the only option right now. It also seems like none of the client code makes it particularly easy toggle it. We are going to get a lot of questions about this (once we actually get it released..).

        Thinking about it, I guess people already could already have prevented use of PLAIN [without SSL] if they wanted to using the previous pn_sasl_allowed_mechs config method? In which case there may not be a need for a specific toggle if we flipped the default, though I can see it would still be easier to use that than setting 'everything but PLAIN' as the allowed mechs. (EDIT: client side that is, server side needs a toggle I guess if it wants to accept SSL and non SSL connections)

        New side thought based on above, what happens currently if the allowed mech(s) are set to include only PLAIN (which I can see folks doing when trying to figure out why it doesnt work anymore) but its actual use is prevented by the transport defaults? Would people get the error Gordon was hunting for above, or something more specific since its detectable in advance that there are no usable mechs?

        Show
        gemmellr Robbie Gemmell added a comment - - edited I'm increasingly feeling that this new option should be flipped so that PLAIN works by default and those that want to restrict it to SSL only can use it to do so. As mentioned earlier, it seems inconsistent to me to allow ANONYMOUS and no-SASL by default but deny PLAIN. It should only be used for lack of a better option, and yet we know there are times it is going to be the only option right now. It also seems like none of the client code makes it particularly easy toggle it. We are going to get a lot of questions about this (once we actually get it released..). Thinking about it, I guess people already could already have prevented use of PLAIN [without SSL] if they wanted to using the previous pn_sasl_allowed_mechs config method? In which case there may not be a need for a specific toggle if we flipped the default, though I can see it would still be easier to use that than setting 'everything but PLAIN' as the allowed mechs. (EDIT: client side that is, server side needs a toggle I guess if it wants to accept SSL and non SSL connections) New side thought based on above, what happens currently if the allowed mech(s) are set to include only PLAIN (which I can see folks doing when trying to figure out why it doesnt work anymore) but its actual use is prevented by the transport defaults? Would people get the error Gordon was hunting for above, or something more specific since its detectable in advance that there are no usable mechs?
        Hide
        gsim Gordon Sim added a comment -

        Even modifying the code to set that property as soon as the transport is created doesn't work.

        Show
        gsim Gordon Sim added a comment - Even modifying the code to set that property as soon as the transport is created doesn't work.
        Hide
        gsim Gordon Sim added a comment -

        I think errors like this should be visible by default without needing to set some obscure environment variable.

        Show
        gsim Gordon Sim added a comment - I think errors like this should be visible by default without needing to set some obscure environment variable.
        Hide
        gsim Gordon Sim added a comment -

        I think my preferred option would also be to allow PLAIN regardless of whether SSL is in use by default, but to clearly log a warning every time PLAIN is used over an unencrypted transport (along with a brief message as to how to prevent this). That way people become very aware of the problem and how to avoid it, but it doesn't cause hard to debug issues when first trying to get an example running.

        Show
        gsim Gordon Sim added a comment - I think my preferred option would also be to allow PLAIN regardless of whether SSL is in use by default, but to clearly log a warning every time PLAIN is used over an unencrypted transport (along with a brief message as to how to prevent this). That way people become very aware of the problem and how to avoid it, but it doesn't cause hard to debug issues when first trying to get an example running.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit a1888591789d3db2ebd6016d7e7d112902e07598 in qpid-proton's branch refs/heads/master from Andrew Stitcher
        [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a188859 ]

        PROTON-950: Add a flag to the messenger API to allow PLAIN over an unencrypted connection

        Show
        jira-bot ASF subversion and git services added a comment - Commit a1888591789d3db2ebd6016d7e7d112902e07598 in qpid-proton's branch refs/heads/master from Andrew Stitcher [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a188859 ] PROTON-950 : Add a flag to the messenger API to allow PLAIN over an unencrypted connection
        Hide
        astitcher Andrew Stitcher added a comment -

        Currently the change to the default behaviour of meessenger is not in the 0.10 branch

        Show
        astitcher Andrew Stitcher added a comment - Currently the change to the default behaviour of meessenger is not in the 0.10 branch
        Hide
        gemmellr Robbie Gemmell added a comment -

        Have you managed to get the new option working with the Python bindings? Gordon wasn't able to either after my fruitless earlier attempt.

        Show
        gemmellr Robbie Gemmell added a comment - Have you managed to get the new option working with the Python bindings? Gordon wasn't able to either after my fruitless earlier attempt.
        Hide
        gsim Gordon Sim added a comment -

        I can't get the new flag to work with the reactor, so I don't think this can be closed yet.

        Show
        gsim Gordon Sim added a comment - I can't get the new flag to work with the reactor, so I don't think this can be closed yet.
        Hide
        gsim Gordon Sim added a comment -

        The transport condition at th point of error merely states 'Authentication failed'. That is certainly better than nothing, but it doesn't explain that the reason was that there was no mutually acceptable mechanism as opposed to PLAIN proceeding but the credentials being invalid.

        Show
        gsim Gordon Sim added a comment - The transport condition at th point of error merely states 'Authentication failed'. That is certainly better than nothing, but it doesn't explain that the reason was that there was no mutually acceptable mechanism as opposed to PLAIN proceeding but the credentials being invalid.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit e26e5976db2d32506651deb32d85ddebd631e1f5 in qpid-proton's branch refs/heads/0.10.x from Andrew Stitcher
        [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=e26e597 ]

        PROTON-950: Add a flag to the messenger API to allow PLAIN over an unencrypted connection

        Show
        jira-bot ASF subversion and git services added a comment - Commit e26e5976db2d32506651deb32d85ddebd631e1f5 in qpid-proton's branch refs/heads/0.10.x from Andrew Stitcher [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=e26e597 ] PROTON-950 : Add a flag to the messenger API to allow PLAIN over an unencrypted connection
        Hide
        gsim Gordon Sim added a comment -

        The issues I was having with the reactive API were a combination of user error and PROTON-974. This issue was indeed fixed.

        Show
        gsim Gordon Sim added a comment - The issues I was having with the reactive API were a combination of user error and PROTON-974 . This issue was indeed fixed.
        Hide
        gemmellr Robbie Gemmell added a comment -

        For me it was a case of sensitivity to mechanism order in certain [not entirely understood] situations, where ANONYMOUS was still being picked because it was offered before PLAIN. If other mechanisms were offered later in the list (e.g DIGEST-MD5) they were chosen instead of ANONYMOUS as would be expected. Ensuring PLAIN was offered before ANONYMOUS allowed it to be chosen if the toggle was enabled.

        Show
        gemmellr Robbie Gemmell added a comment - For me it was a case of sensitivity to mechanism order in certain [not entirely understood] situations, where ANONYMOUS was still being picked because it was offered before PLAIN. If other mechanisms were offered later in the list (e.g DIGEST-MD5) they were chosen instead of ANONYMOUS as would be expected. Ensuring PLAIN was offered before ANONYMOUS allowed it to be chosen if the toggle was enabled.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 5a8c6e0b9091c1e43e585b322ea7b01d53eee288 in qpid-proton's branch refs/heads/master from Gordon Sim
        [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5a8c6e0 ]

        PROTON-950: provide Container default for the allow_insecure_mechs property on transport

        Show
        jira-bot ASF subversion and git services added a comment - Commit 5a8c6e0b9091c1e43e585b322ea7b01d53eee288 in qpid-proton's branch refs/heads/master from Gordon Sim [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5a8c6e0 ] PROTON-950 : provide Container default for the allow_insecure_mechs property on transport
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 39b3dd56a38a396791ebcdba30bf4097e74c90d7 in qpid-proton's branch refs/heads/0.10.x from Gordon Sim
        [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=39b3dd5 ]

        PROTON-950: provide Container default for the allow_insecure_mechs property on transport

        Show
        jira-bot ASF subversion and git services added a comment - Commit 39b3dd56a38a396791ebcdba30bf4097e74c90d7 in qpid-proton's branch refs/heads/0.10.x from Gordon Sim [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=39b3dd5 ] PROTON-950 : provide Container default for the allow_insecure_mechs property on transport
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 14956b07edc3de93f67179c753bbedcd9eba51a6 in qpid-proton's branch refs/heads/master from Gordon Sim
        [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=14956b0 ]

        PROTON-950: don't force sasl layer by default

        Show
        jira-bot ASF subversion and git services added a comment - Commit 14956b07edc3de93f67179c753bbedcd9eba51a6 in qpid-proton's branch refs/heads/master from Gordon Sim [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=14956b0 ] PROTON-950 : don't force sasl layer by default

          People

          • Assignee:
            astitcher Andrew Stitcher
            Reporter:
            tedross Ted Ross
          • Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development