Re: SASL / non SASL connections...
Hi Clebert, As a little extra context for readers...with AMQP 1.0, if the client wishes to use SASL security it first establishes a SASL layer beginning with the AMQP%d3.1.0.0 header, and then if successfull proceed to establish the 'regular' AMQP connection over it beginning with the AMQP%d0.1.0.0 header. Details/diagrams at: http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-security-v1.0-os.html#section-sasl As you know, calling the sasl() method on the Proton transport will make it add the sasl layer and expect the relevant header for initial input, and also emit it when sending its initial output. You are thus concerned with how to know whether you should call the sasl() method. Currently you are correct that with proton-j you would have to sniff the traffic in order to support accepting both sasl layered connections and bare connections without sasl. The alternative is that you would always call sasl() and simply be unable to accept connections that skip the sasl layer, and if wishing to support unauthenticated connections for explicit no-auth scenarios doing so by either using the ANONYMOUS mechanism or simply accepting any credentials supplied via others. Ted added support to proton-c in 0.8 for a server to be able to add the transport sasl layer but also be able to identify the client skipped the sasl layer and then optionally allow it to do so by replying with the AMQP%d0.1.0.0 header. I stubbed the API for this in proton-j to get the test suite back running at all, but the functionality has yet to actually be implemented: https://issues.apache.org/jira/browse/PROTON-642 https://issues.apache.org/jira/browse/PROTON-655 I think the JMS clients currently expect the server to offer the SASL layer, and will negotiate the ANONYMOUS mechanism if that is all the server offers. I dont believe either client would currently handle the server replying with the bare connection header in response to them sending the sasl header, and I don't believe the new client yet supports skipping sending the SASL header but it looks like the old one might if provided with a null username. Robbie On 14 October 2014 19:20, Clebert Suconic csuco...@redhat.com wrote: qpid JMS clients currently expect to send anonymous connection in the following way: - if the first frame has the SASL byte 3 (I'm not reading the spec now.. I'm not sure the correct term), the server is supposed to initialize SASL on the connection, transport... etc In other terms, if the following frame arrives, we need to create SASL with the proper capabilities: 414D5150 --03--01 * just as a reference for general audience, 414D5150 == AMQP in ascii terms - if that byte is 0, then the JMS client is expecting to have the server's session being anonymous. 414D5150 --00-- 01 With that I have two questions: - What is the SASL Anonymous for then if clients are expected to dictate if they will use SASL or not? I was expecting it being a server's directive.. to either use SASL or not? - If you need that capability for sure.. there's currently no way to use Proton to determine if we need SASL or not. The only way I could find was to inspect the first byte 4 (starting at 0) on the protocol and initialize SASL. Couldn't (or Shouldn't?) we have an event such as SASL_INIT from Proton and then we make the proper determination? Maybe I missed the proper API if there's a way around this already!
[jira] [Created] (PROTON-713) TransportImpl#setChannelMax does not enforce legal value range, may cause unexpected results
Robbie Gemmell created PROTON-713: - Summary: TransportImpl#setChannelMax does not enforce legal value range, may cause unexpected results Key: PROTON-713 URL: https://issues.apache.org/jira/browse/PROTON-713 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Robbie Gemmell Priority: Minor Whilst helping debug an issue yesterday with Tim (which turned out to be with the old Qpid 0.2X/0.3X AMQP 1.0 JMS client), we noticed some unexpected results from using Transport#setChannelMax method. The chanel-max field of the Open frame is a ushort. The API expsoses this via the signed Java int to allow easily onfiguring the values outwith the signed short range. When using the value in TransportImp, it is cast to a short, which truncates the bit length of the value and may turn it negative (which is expected by the UnsignedShort wrapper). If a value over 2^16-1 is used, you thus do not get quite what you expect, and if you happen to use 2^16 then you will actually see 0. {noformat} if (_channelMax 0) { open.setChannelMax(UnsignedShort.valueOf((short) _channelMax)); } {noformat} The legal range should be enforced so that the outgoing Open frame actually contains what the user asked for, and the legal values are clear. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-714) SSL buffer overflow with large frames
Rafael H. Schloming created PROTON-714: -- Summary: SSL buffer overflow with large frames Key: PROTON-714 URL: https://issues.apache.org/jira/browse/PROTON-714 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-714) SSL buffer overflow with large frames
[ https://issues.apache.org/jira/browse/PROTON-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172322#comment-14172322 ] Rafael H. Schloming commented on PROTON-714: From an email thread: I am developing an application that acts as an AMQP Client, using an SSL connection on a topic. The messages received on this topic are quite large and for each message I catch the following Exception: java.nio.BufferOverflowException at java.nio.HeapByteBuffer.put(Unknown Source) at org.apache.qpid.proton.engine.impl.ssl.SimpleSslTransportWrapper.unwrapInput (SimpleSslTransportWrapper.java:128) at org.apache.qpid.proton.engine.impl.ssl.SimpleSslTransportWrapper.process(Sim pleSslTransportWrapper.java:344) at org.apache.qpid.proton.engine.impl.ssl.SslImpl$UnsecureClientAwareTransportW rapper.process(SslImpl.java:132) at org.apache.qpid.proton.engine.impl.TransportImpl.process(TransportImpl.java: 1265) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:136 ) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java: 95) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerI mpl.java:743) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl. java:895) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl. java:853) at org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java: 451) at org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java: 456) at com.oraise.Receiver.run(Receiver.java:30) SSL buffer overflow with large frames - Key: PROTON-714 URL: https://issues.apache.org/jira/browse/PROTON-714 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-714) SSL buffer overflow with large frames
[ https://issues.apache.org/jira/browse/PROTON-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172325#comment-14172325 ] ASF subversion and git services commented on PROTON-714: Commit 1632004 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1632004 ] PROTON-714: don't overflow the input buffer SSL buffer overflow with large frames - Key: PROTON-714 URL: https://issues.apache.org/jira/browse/PROTON-714 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: SASL / non SASL connections...
What Ted already implemented on the C side would enable what you are seeking, allowing the server to be configured (depending on your security configuration; some wouldnt want the without-sasl case to ever work, other may allow it in no-auth scenarios) to accept either the sasl or non sasl header as the first bytes and respond appropriately. The JIRA for the Java side just hasnt been implemented yet. Generating an event to say the sasl header was received might not work that well, as you currently need to pump the bytes into the transport for it to generate events, and it currently needs to know in advance how to process any bytes that come after the header (the client could for example pipeline the entire sasl 'negotiation' and well beyond, on assumption the authentication or lack thereof will be successfull). Making the sasl process interface nicer with the events stuff in general is something I would like to see happen, though not something I currently have time to look at though. Robbie On 15 October 2014 15:15, Clebert Suconic csuco...@redhat.com wrote: I think you should have an event for SASL_NEGOTATION.. or any name you chose.. then you could negotiate it properly. I don't think it would be too hard to implement. The clients I'm working don't know how to negotiate ANONYMOUS. All the Java clients I'm dealing with now will throw a bad NPE if I don't have this behaviour. Should we raise a JIRA? On Oct 15, 2014, at 6:07 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi Clebert, As a little extra context for readers...with AMQP 1.0, if the client wishes to use SASL security it first establishes a SASL layer beginning with the AMQP%d3.1.0.0 header, and then if successfull proceed to establish the 'regular' AMQP connection over it beginning with the AMQP%d0.1.0.0 header. Details/diagrams at: http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-security-v1.0-os.html#section-sasl As you know, calling the sasl() method on the Proton transport will make it add the sasl layer and expect the relevant header for initial input, and also emit it when sending its initial output. You are thus concerned with how to know whether you should call the sasl() method. Currently you are correct that with proton-j you would have to sniff the traffic in order to support accepting both sasl layered connections and bare connections without sasl. The alternative is that you would always call sasl() and simply be unable to accept connections that skip the sasl layer, and if wishing to support unauthenticated connections for explicit no-auth scenarios doing so by either using the ANONYMOUS mechanism or simply accepting any credentials supplied via others. Ted added support to proton-c in 0.8 for a server to be able to add the transport sasl layer but also be able to identify the client skipped the sasl layer and then optionally allow it to do so by replying with the AMQP%d0.1.0.0 header. I stubbed the API for this in proton-j to get the test suite back running at all, but the functionality has yet to actually be implemented: https://issues.apache.org/jira/browse/PROTON-642 https://issues.apache.org/jira/browse/PROTON-655 I think the JMS clients currently expect the server to offer the SASL layer, and will negotiate the ANONYMOUS mechanism if that is all the server offers. I dont believe either client would currently handle the server replying with the bare connection header in response to them sending the sasl header, and I don't believe the new client yet supports skipping sending the SASL header but it looks like the old one might if provided with a null username. Robbie On 14 October 2014 19:20, Clebert Suconic csuco...@redhat.com wrote: qpid JMS clients currently expect to send anonymous connection in the following way: - if the first frame has the SASL byte 3 (I'm not reading the spec now.. I'm not sure the correct term), the server is supposed to initialize SASL on the connection, transport... etc In other terms, if the following frame arrives, we need to create SASL with the proper capabilities: 414D5150 --03--01 * just as a reference for general audience, 414D5150 == AMQP in ascii terms - if that byte is 0, then the JMS client is expecting to have the server's session being anonymous. 414D5150 --00-- 01 With that I have two questions: - What is the SASL Anonymous for then if clients are expected to dictate if they will use SASL or not? I was expecting it being a server's directive.. to either use SASL or not? - If you need that capability for sure.. there's currently no way to use Proton to determine if we need SASL or not. The only way I could find was to inspect the first byte 4 (starting at 0) on the protocol and initialize SASL. Couldn't (or Shouldn't?) we have an event such as SASL_INIT from Proton and then we
[jira] [Assigned] (PROTON-712) Seg fault due to missing NULL return value check of getprotobyname
[ https://issues.apache.org/jira/browse/PROTON-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reassigned PROTON-712: -- Assignee: Rafael H. Schloming Seg fault due to missing NULL return value check of getprotobyname -- Key: PROTON-712 URL: https://issues.apache.org/jira/browse/PROTON-712 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Sahir Hoda Assignee: Rafael H. Schloming Labels: easyfix, patch Attachments: getprotobyname-err-check.patch There are several places proton-c makes calls to getprotobyname and dereferences the return value without checking for NULL first. Documentation for getprotobyname indicates it can return NULL if there was an error. We have seen seg faults in testing where getprotobyname returned NULL. Attached is a patch that adds some simple error checking to the getprotobyname call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: SASL / non SASL connections...
On Oct 15, 2014, at 11:09 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: What Ted already implemented on the C side would enable what you are seeking, allowing the server to be configured (depending on your security configuration; some wouldnt want the without-sasl case to ever work, other may allow it in no-auth scenarios) to accept either the sasl or non sasl header as the first bytes and respond appropriately. The JIRA for the Java side just hasnt been implemented yet. Generating an event to say the sasl header was received might not work that well, as you currently need to pump the bytes into the transport for it to generate events, and it currently needs to know in advance how to process any bytes that come after the header (the client could for example pipeline the entire sasl 'negotiation' and well beyond, on assumption the authentication or lack thereof will be successfull). Making the sasl process interface nicer with the events stuff in general is something I would like to see happen, though not something I currently have time to look at though. I thought about the even being generated before SASL headers were created. I event would work if implemented at the proper place. But if you already have a solution for that.. it's all good... thanks Robbie Robbie On 15 October 2014 15:15, Clebert Suconic csuco...@redhat.com wrote: I think you should have an event for SASL_NEGOTATION.. or any name you chose.. then you could negotiate it properly. I don't think it would be too hard to implement. The clients I'm working don't know how to negotiate ANONYMOUS. All the Java clients I'm dealing with now will throw a bad NPE if I don't have this behaviour. Should we raise a JIRA? On Oct 15, 2014, at 6:07 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi Clebert, As a little extra context for readers...with AMQP 1.0, if the client wishes to use SASL security it first establishes a SASL layer beginning with the AMQP%d3.1.0.0 header, and then if successfull proceed to establish the 'regular' AMQP connection over it beginning with the AMQP%d0.1.0.0 header. Details/diagrams at: http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-security-v1.0-os.html#section-sasl As you know, calling the sasl() method on the Proton transport will make it add the sasl layer and expect the relevant header for initial input, and also emit it when sending its initial output. You are thus concerned with how to know whether you should call the sasl() method. Currently you are correct that with proton-j you would have to sniff the traffic in order to support accepting both sasl layered connections and bare connections without sasl. The alternative is that you would always call sasl() and simply be unable to accept connections that skip the sasl layer, and if wishing to support unauthenticated connections for explicit no-auth scenarios doing so by either using the ANONYMOUS mechanism or simply accepting any credentials supplied via others. Ted added support to proton-c in 0.8 for a server to be able to add the transport sasl layer but also be able to identify the client skipped the sasl layer and then optionally allow it to do so by replying with the AMQP%d0.1.0.0 header. I stubbed the API for this in proton-j to get the test suite back running at all, but the functionality has yet to actually be implemented: https://issues.apache.org/jira/browse/PROTON-642 https://issues.apache.org/jira/browse/PROTON-655 I think the JMS clients currently expect the server to offer the SASL layer, and will negotiate the ANONYMOUS mechanism if that is all the server offers. I dont believe either client would currently handle the server replying with the bare connection header in response to them sending the sasl header, and I don't believe the new client yet supports skipping sending the SASL header but it looks like the old one might if provided with a null username. Robbie On 14 October 2014 19:20, Clebert Suconic csuco...@redhat.com wrote: qpid JMS clients currently expect to send anonymous connection in the following way: - if the first frame has the SASL byte 3 (I'm not reading the spec now.. I'm not sure the correct term), the server is supposed to initialize SASL on the connection, transport... etc In other terms, if the following frame arrives, we need to create SASL with the proper capabilities: 414D5150 --03--01 * just as a reference for general audience, 414D5150 == AMQP in ascii terms - if that byte is 0, then the JMS client is expecting to have the server's session being anonymous. 414D5150 --00-- 01 With that I have two questions: - What is the SASL Anonymous for then if clients are expected to dictate if they will use SASL or not? I was expecting it being a server's directive.. to either use SASL or not? - If you need that capability for sure.. there's
[jira] [Created] (PROTON-715) [contrib/proton-jms] delivery-count is set incorrectly during Native outbound transformation
Robbie Gemmell created PROTON-715: - Summary: [contrib/proton-jms] delivery-count is set incorrectly during Native outbound transformation Key: PROTON-715 URL: https://issues.apache.org/jira/browse/PROTON-715 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.7 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.8 In the proton-jms contrib artifact, delivery-count is set incorrectly (based on JMSXDeliveryCount) during outbound JMS message transformation. The value set is the same as the JMSXDeliveryCount value encountered, which is incorrect as the two have different semantics. The delivery-count field in the AMQP 1.0 message header tracks prior unsuccessful delivery attempts and so should go 0,1,2 etc if set. JMSXDeliveryCount property in JMS tracks the total number of delivery attempts, and should go 1,2,3. As such, delivery-count should be 1 less than JMSXDeliveryCount, not equal to it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-715) [contrib/proton-jms] delivery-count is set incorrectly during Native outbound transformation
[ https://issues.apache.org/jira/browse/PROTON-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-715: -- Description: In the proton-jms contrib artifact, delivery-count is set incorrectly (based on JMSXDeliveryCount) during outbound 'Native' message transformation. The value set is the same as the JMSXDeliveryCount value encountered, which is incorrect as the two have different semantics. The delivery-count field in the AMQP 1.0 message header tracks prior unsuccessful delivery attempts and so should go 0,1,2 etc if set. JMSXDeliveryCount property in JMS tracks the total number of delivery attempts, and should go 1,2,3. As such, delivery-count should be 1 less than JMSXDeliveryCount, not equal to it. was: In the proton-jms contrib artifact, delivery-count is set incorrectly (based on JMSXDeliveryCount) during outbound JMS message transformation. The value set is the same as the JMSXDeliveryCount value encountered, which is incorrect as the two have different semantics. The delivery-count field in the AMQP 1.0 message header tracks prior unsuccessful delivery attempts and so should go 0,1,2 etc if set. JMSXDeliveryCount property in JMS tracks the total number of delivery attempts, and should go 1,2,3. As such, delivery-count should be 1 less than JMSXDeliveryCount, not equal to it. [contrib/proton-jms] delivery-count is set incorrectly during Native outbound transformation Key: PROTON-715 URL: https://issues.apache.org/jira/browse/PROTON-715 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.7 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.8 In the proton-jms contrib artifact, delivery-count is set incorrectly (based on JMSXDeliveryCount) during outbound 'Native' message transformation. The value set is the same as the JMSXDeliveryCount value encountered, which is incorrect as the two have different semantics. The delivery-count field in the AMQP 1.0 message header tracks prior unsuccessful delivery attempts and so should go 0,1,2 etc if set. JMSXDeliveryCount property in JMS tracks the total number of delivery attempts, and should go 1,2,3. As such, delivery-count should be 1 less than JMSXDeliveryCount, not equal to it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-715) [contrib/proton-jms] delivery-count is set incorrectly during Native outbound transformation
[ https://issues.apache.org/jira/browse/PROTON-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172472#comment-14172472 ] ASF subversion and git services commented on PROTON-715: Commit 1632091 from [~gemmellr] in branch 'proton/trunk' [ https://svn.apache.org/r1632091 ] PROTON-715: subtract 1 when setting delivery-count header based on JMSXDeliveryCount during outbound Native transformation [contrib/proton-jms] delivery-count is set incorrectly during Native outbound transformation Key: PROTON-715 URL: https://issues.apache.org/jira/browse/PROTON-715 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.7 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.8 In the proton-jms contrib artifact, delivery-count is set incorrectly (based on JMSXDeliveryCount) during outbound 'Native' message transformation. The value set is the same as the JMSXDeliveryCount value encountered, which is incorrect as the two have different semantics. The delivery-count field in the AMQP 1.0 message header tracks prior unsuccessful delivery attempts and so should go 0,1,2 etc if set. JMSXDeliveryCount property in JMS tracks the total number of delivery attempts, and should go 1,2,3. As such, delivery-count should be 1 less than JMSXDeliveryCount, not equal to it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-712) Seg fault due to missing NULL return value check of getprotobyname
[ https://issues.apache.org/jira/browse/PROTON-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172473#comment-14172473 ] ASF subversion and git services commented on PROTON-712: Commit 1632092 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1632092 ] PROTON-712: check getprotobyname for NULL return value (patch from Sahir Hoda) Seg fault due to missing NULL return value check of getprotobyname -- Key: PROTON-712 URL: https://issues.apache.org/jira/browse/PROTON-712 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Sahir Hoda Assignee: Rafael H. Schloming Labels: easyfix, patch Attachments: getprotobyname-err-check.patch There are several places proton-c makes calls to getprotobyname and dereferences the return value without checking for NULL first. Documentation for getprotobyname indicates it can return NULL if there was an error. We have seen seg faults in testing where getprotobyname returned NULL. Attached is a patch that adds some simple error checking to the getprotobyname call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-712) Seg fault due to missing NULL return value check of getprotobyname
[ https://issues.apache.org/jira/browse/PROTON-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-712. Resolution: Fixed Fix Version/s: 0.8 Seg fault due to missing NULL return value check of getprotobyname -- Key: PROTON-712 URL: https://issues.apache.org/jira/browse/PROTON-712 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Sahir Hoda Assignee: Rafael H. Schloming Labels: easyfix, patch Fix For: 0.8 Attachments: getprotobyname-err-check.patch There are several places proton-c makes calls to getprotobyname and dereferences the return value without checking for NULL first. Documentation for getprotobyname indicates it can return NULL if there was an error. We have seen seg faults in testing where getprotobyname returned NULL. Attached is a patch that adds some simple error checking to the getprotobyname call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-715) [contrib/proton-jms] delivery-count is set incorrectly during Native outbound transformation
[ https://issues.apache.org/jira/browse/PROTON-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-715. --- Resolution: Fixed [contrib/proton-jms] delivery-count is set incorrectly during Native outbound transformation Key: PROTON-715 URL: https://issues.apache.org/jira/browse/PROTON-715 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.7 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.8 In the proton-jms contrib artifact, delivery-count is set incorrectly (based on JMSXDeliveryCount) during outbound 'Native' message transformation. The value set is the same as the JMSXDeliveryCount value encountered, which is incorrect as the two have different semantics. The delivery-count field in the AMQP 1.0 message header tracks prior unsuccessful delivery attempts and so should go 0,1,2 etc if set. JMSXDeliveryCount property in JMS tracks the total number of delivery attempts, and should go 1,2,3. As such, delivery-count should be 1 less than JMSXDeliveryCount, not equal to it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-708) C proton driver needs a getter function to access the pn_error so it can be cleared
[ https://issues.apache.org/jira/browse/PROTON-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reassigned PROTON-708: -- Assignee: Rafael H. Schloming C proton driver needs a getter function to access the pn_error so it can be cleared --- Key: PROTON-708 URL: https://issues.apache.org/jira/browse/PROTON-708 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Jesse Fugitt Assignee: Rafael H. Schloming Our team is currently using Proton 0.7 and ran into an issue on Windows while testing where we could not successfully reconnect to a broker once it was taken down and brought back up (we are using a pn_driver_t in C). It appears that having the ability to clear the pn_error_t stored in the driver struct would have solved the issue for us. I'll include some of the details below that were also sent to the mailing list but the solution is probably a pretty easy fix that just involves adding a function to the driver that simply returns its pn_error_t field. Details The Proton library's Driver Module (both Posix and Windows) does not supply a mechanism to clear an error that was detected. In contrast, other modules such as Connection supply a method to obtain the pn_error_t structure (see pn_connection_error()). This method can be used in combination with pn_error_clear() to clear an error. It was observed that when establishing a connection from Windows to a potential broker on Linux that a WSAECONNREFUSED can be returned from the connect() call if the broker is not running. This results in a call to select() with a -1 file descriptor. The select() returns a socket error which is recorded in the Error Module. The error number can be obtained using the pn_driver_errno() call. Deleting the Connection and therefore removing the erroneous -1 file description results in subsequent successful select() calls. However, querying the Driver module for an error will perpetually return the last error. There is no mechanism to clear that error. A small patch to the driver.c below is working for us currently but we wanted input on what the best or more general solution to the problem should be: return d ? pn_error_code(d-error) : PN_ARG_ERR; --- int rtn = PN_ARG_ERR; if (d) { rtn = pn_error_code(d-error); pn_error_clear(d-error); } return rtn; On the mailing list, Rafael said his preference would be to expose the driver's pn_error_t as the other modules do so it can be cleared rather than auto-clearing it as we do in the sample patch above. However, the pn_driver_error function already exists so either we need to break convention with the other modules in terms of the function name or break compatibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-708) C proton driver needs a getter function to access the pn_error so it can be cleared
[ https://issues.apache.org/jira/browse/PROTON-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172492#comment-14172492 ] ASF subversion and git services commented on PROTON-708: Commit 1632098 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1632098 ] PROTON-708: changed pn_driver_error to return the pn_error_t C proton driver needs a getter function to access the pn_error so it can be cleared --- Key: PROTON-708 URL: https://issues.apache.org/jira/browse/PROTON-708 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Jesse Fugitt Assignee: Rafael H. Schloming Our team is currently using Proton 0.7 and ran into an issue on Windows while testing where we could not successfully reconnect to a broker once it was taken down and brought back up (we are using a pn_driver_t in C). It appears that having the ability to clear the pn_error_t stored in the driver struct would have solved the issue for us. I'll include some of the details below that were also sent to the mailing list but the solution is probably a pretty easy fix that just involves adding a function to the driver that simply returns its pn_error_t field. Details The Proton library's Driver Module (both Posix and Windows) does not supply a mechanism to clear an error that was detected. In contrast, other modules such as Connection supply a method to obtain the pn_error_t structure (see pn_connection_error()). This method can be used in combination with pn_error_clear() to clear an error. It was observed that when establishing a connection from Windows to a potential broker on Linux that a WSAECONNREFUSED can be returned from the connect() call if the broker is not running. This results in a call to select() with a -1 file descriptor. The select() returns a socket error which is recorded in the Error Module. The error number can be obtained using the pn_driver_errno() call. Deleting the Connection and therefore removing the erroneous -1 file description results in subsequent successful select() calls. However, querying the Driver module for an error will perpetually return the last error. There is no mechanism to clear that error. A small patch to the driver.c below is working for us currently but we wanted input on what the best or more general solution to the problem should be: return d ? pn_error_code(d-error) : PN_ARG_ERR; --- int rtn = PN_ARG_ERR; if (d) { rtn = pn_error_code(d-error); pn_error_clear(d-error); } return rtn; On the mailing list, Rafael said his preference would be to expose the driver's pn_error_t as the other modules do so it can be cleared rather than auto-clearing it as we do in the sample patch above. However, the pn_driver_error function already exists so either we need to break convention with the other modules in terms of the function name or break compatibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-708) C proton driver needs a getter function to access the pn_error so it can be cleared
[ https://issues.apache.org/jira/browse/PROTON-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-708. Resolution: Fixed Fix Version/s: 0.8 C proton driver needs a getter function to access the pn_error so it can be cleared --- Key: PROTON-708 URL: https://issues.apache.org/jira/browse/PROTON-708 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Jesse Fugitt Assignee: Rafael H. Schloming Fix For: 0.8 Our team is currently using Proton 0.7 and ran into an issue on Windows while testing where we could not successfully reconnect to a broker once it was taken down and brought back up (we are using a pn_driver_t in C). It appears that having the ability to clear the pn_error_t stored in the driver struct would have solved the issue for us. I'll include some of the details below that were also sent to the mailing list but the solution is probably a pretty easy fix that just involves adding a function to the driver that simply returns its pn_error_t field. Details The Proton library's Driver Module (both Posix and Windows) does not supply a mechanism to clear an error that was detected. In contrast, other modules such as Connection supply a method to obtain the pn_error_t structure (see pn_connection_error()). This method can be used in combination with pn_error_clear() to clear an error. It was observed that when establishing a connection from Windows to a potential broker on Linux that a WSAECONNREFUSED can be returned from the connect() call if the broker is not running. This results in a call to select() with a -1 file descriptor. The select() returns a socket error which is recorded in the Error Module. The error number can be obtained using the pn_driver_errno() call. Deleting the Connection and therefore removing the erroneous -1 file description results in subsequent successful select() calls. However, querying the Driver module for an error will perpetually return the last error. There is no mechanism to clear that error. A small patch to the driver.c below is working for us currently but we wanted input on what the best or more general solution to the problem should be: return d ? pn_error_code(d-error) : PN_ARG_ERR; --- int rtn = PN_ARG_ERR; if (d) { rtn = pn_error_code(d-error); pn_error_clear(d-error); } return rtn; On the mailing list, Rafael said his preference would be to expose the driver's pn_error_t as the other modules do so it can be cleared rather than auto-clearing it as we do in the sample patch above. However, the pn_driver_error function already exists so either we need to break convention with the other modules in terms of the function name or break compatibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-676) proton-c: transport layer SSL failures not propagated back to Messenger in pni_connection_readable
[ https://issues.apache.org/jira/browse/PROTON-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-676. Resolution: Fixed proton-c: transport layer SSL failures not propagated back to Messenger in pni_connection_readable -- Key: PROTON-676 URL: https://issues.apache.org/jira/browse/PROTON-676 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Rafael H. Schloming Fix For: 0.8 Attachments: 24_ssl_transport_failure_fix_messenger.c.patch When an ssl failure occurs during connection at the transport layer the error is not propagated back to messenger (it is ignored). Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
VOTE: Release Proton 0.8 RC3 as 0.8 final
Hi Everyone, As usual the call for a formal vote flushed out a few last minute issues, so here is a quick respin with the following items fixed. - PROTON-708 - PROTON-711 (fixed for Java6) - PROTON-712 - PROTON-714 - PROTON-715 The sources can be found at the usual location: http://people.apache.org/~rhs/qpid-proton-0.8rc3/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-1018 Please check them out and register your vote: [ ] Yes, release Proton 0.8 RC3 as 0.8 final [ ] No, because ... --Rafael
[jira] [Created] (PROTON-716) Reject SSL clients that attempt to use SSLv3
Ken Giusti created PROTON-716: - Summary: Reject SSL clients that attempt to use SSLv3 Key: PROTON-716 URL: https://issues.apache.org/jira/browse/PROTON-716 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Ken Giusti SSLv3 is vulnerable to CVE-2014-3566, and will not fixed. See: https://securityblog.redhat.com/2014/10/15/poodle-a-ssl3-vulnerability-cve-2014-3566/ By default, all clients based on Proton/C will use TLSv1 and are therefore not affected by this CVE. However, a server based on Proton/C will allow clients to connect using either TLSv1 or SSLv3, as it allowed for older clients that had not upgraded to SSLv3. Since SSLv3 is no longer considered secure, we should prevent Proton/C from accepting v3-based SSL connections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-716) Reject SSL clients that attempt to use SSLv3
[ https://issues.apache.org/jira/browse/PROTON-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172881#comment-14172881 ] Ken Giusti commented on PROTON-716: --- Reviewboard: https://reviews.apache.org/r/26773/ Reject SSL clients that attempt to use SSLv3 Key: PROTON-716 URL: https://issues.apache.org/jira/browse/PROTON-716 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Ken Giusti SSLv3 is vulnerable to CVE-2014-3566, and will not fixed. See: https://securityblog.redhat.com/2014/10/15/poodle-a-ssl3-vulnerability-cve-2014-3566/ By default, all clients based on Proton/C will use TLSv1 and are therefore not affected by this CVE. However, a server based on Proton/C will allow clients to connect using either TLSv1 or SSLv3, as it allowed for older clients that had not upgraded to SSLv3. Since SSLv3 is no longer considered secure, we should prevent Proton/C from accepting v3-based SSL connections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-716) Reject SSL clients that attempt to use SSLv3
[ https://issues.apache.org/jira/browse/PROTON-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-716: - Assignee: Ken Giusti Reject SSL clients that attempt to use SSLv3 Key: PROTON-716 URL: https://issues.apache.org/jira/browse/PROTON-716 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Ken Giusti Assignee: Ken Giusti SSLv3 is vulnerable to CVE-2014-3566, and will not fixed. See: https://securityblog.redhat.com/2014/10/15/poodle-a-ssl3-vulnerability-cve-2014-3566/ By default, all clients based on Proton/C will use TLSv1 and are therefore not affected by this CVE. However, a server based on Proton/C will allow clients to connect using either TLSv1 or SSLv3, as it allowed for older clients that had not upgraded to SSLv3. Since SSLv3 is no longer considered secure, we should prevent Proton/C from accepting v3-based SSL connections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-716) Reject SSL clients that attempt to use SSLv3
[ https://issues.apache.org/jira/browse/PROTON-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172907#comment-14172907 ] ASF subversion and git services commented on PROTON-716: Commit 1632175 from [~kgiusti] in branch 'proton/trunk' [ https://svn.apache.org/r1632175 ] PROTON-716: reject connections using SSLv3 - it is insecure Reject SSL clients that attempt to use SSLv3 Key: PROTON-716 URL: https://issues.apache.org/jira/browse/PROTON-716 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Ken Giusti Assignee: Ken Giusti SSLv3 is vulnerable to CVE-2014-3566, and will not fixed. See: https://securityblog.redhat.com/2014/10/15/poodle-a-ssl3-vulnerability-cve-2014-3566/ By default, all clients based on Proton/C will use TLSv1 and are therefore not affected by this CVE. However, a server based on Proton/C will allow clients to connect using either TLSv1 or SSLv3, as it allowed for older clients that had not upgraded to SSLv3. Since SSLv3 is no longer considered secure, we should prevent Proton/C from accepting v3-based SSL connections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)