[jira] [Resolved] (PROTON-35) Convert to a maven multi-module build
[ https://issues.apache.org/jira/browse/PROTON-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved PROTON-35. - Resolution: Fixed Fix Version/s: 0.3 PROTON-140 implemented the multi-module build. Convert to a maven multi-module build - Key: PROTON-35 URL: https://issues.apache.org/jira/browse/PROTON-35 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Hiram Chirino Priority: Minor Fix For: 0.3 Attachments: PROTON-35.patch Having a multi-module build just means having a pom.xml at the root of the project. This way it will be easier to add additional optional modules in the future and setup CI builds of the java bits. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-154) link attach, detach, attach sequence on single session does not result in a new link for the 2nd attach
[
https://issues.apache.org/jira/browse/PROTON-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiram Chirino updated PROTON-154:
-
Attachment: PROTON-154.patch
attaching possible fix.
link attach, detach, attach sequence on single session does not result in a
new link for the 2nd attach
---
Key: PROTON-154
URL: https://issues.apache.org/jira/browse/PROTON-154
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Reporter: Hiram Chirino
Attachments: PROTON-154.patch
Protocol trace:
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | SENT: Attach{name='topic', handle=1, role=SENDER,
sndSettleMode=2, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | RECV: Flow{nextIncomingId=1, incomingWindow=2048,
nextOutgoingId=0, outgoingWindow=2048, handle=1, deliveryCount=0,
linkCredit=100, available=null, drain=false, echo=false, properties=null}
tcp://127.0.0.1:58348 | RECV: Detach{handle=1, closed=true, error=null}
tcp://127.0.0.1:58348 | SENT: Detach{handle=1, closed=false, error=null}
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0, source=null,
target=Target{address='644cf32c-d6c7-45eb-a8b7-3018d4c9594e', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
no link is produced on the second attach when you call:
protonConnection.linkHead(UNINITIALIZED_SET, INITIALIZED_SET);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-165) SSL: provide access to the certificate provided by the peer (Java implementation)
Philip Harvey created PROTON-165: Summary: SSL: provide access to the certificate provided by the peer (Java implementation) Key: PROTON-165 URL: https://issues.apache.org/jira/browse/PROTON-165 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Philip Harvey This is the Java-equivalent of the change being made in PROTON-90 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-90) SSL: provide access to the certificate provided by the peer.
[ https://issues.apache.org/jira/browse/PROTON-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504526#comment-13504526 ] Philip Harvey commented on PROTON-90: - Hi, do you have a view on how the api should be modified to achieve this? The reason I ask is so PROTON-165 can expose it in a similar way. SSL: provide access to the certificate provided by the peer. Key: PROTON-90 URL: https://issues.apache.org/jira/browse/PROTON-90 Project: Qpid Proton Issue Type: New Feature Components: proton-c Reporter: Ken Giusti Currently, the SSL implementation merely verifies that the certificate supplied by the remote is signed by the configured CA. There is no way to extract information from that certificate - such as the CN, subject, etc. It would be useful to provide an accessor api to get at the contents of the certificate. This could be used by the application to, for example, verify the CN and decide whether or not to close the connection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-166) message.h: pn_message() should be declared pn_message(void)
Glenn McClements created PROTON-166: --- Summary: message.h: pn_message() should be declared pn_message(void) Key: PROTON-166 URL: https://issues.apache.org/jira/browse/PROTON-166 Project: Qpid Proton Issue Type: Bug Components: proton-c Environment: CentOS release 5.5, GCC 4.1.2 Reporter: Glenn McClements Priority: Trivial Depending on the strictness settings of the compiler, declaring a function with no arguments (as opposed to a void argument) causes a warning. /home/glenn/dev/OpenMAMA/Proton/trunk/proton-c/build//include/proton/message.h:45: warning: function declaration isn't a prototype -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-167) Expose pn_type_str (pn_type_t type) publicly
Glenn McClements created PROTON-167: --- Summary: Expose pn_type_str (pn_type_t type) publicly Key: PROTON-167 URL: https://issues.apache.org/jira/browse/PROTON-167 Project: Qpid Proton Issue Type: Wish Components: proton-c Environment: CentOS release 5.5, GCC 4.1.2 Reporter: Glenn McClements Priority: Trivial pn_type_str () is useful for debugging/testing so it would be nice to be exposed for developers as standard. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-136) Add support for SSL session resumption
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504682#comment-13504682 ] Rafael H. Schloming commented on PROTON-136: Ken: A couple comments on the API proposal. I think given the fact that we have pn_session_t and pn_link_t elsewhere in the API, the pn_ssl_session_t and pn_ssl_link_t names are somewhat unfortunate. ;-) I'd also suggest that we can probably do what you're suggesting while preserving compatibility with the current API if we split the other way, i.e. introduce a new object for the top level and keep pn_ssl_t as the per transport thing. For example we could introduce pn_ssl_config_t that can encapsulate all the credential config stuff that you can currently do directly on pn_ssl_t. We could then provide the option to configure a pn_ssl_t by supplying a pn_ssl_config_t wholesale. We could then deprecate and later remove the credential related stuff on pn_ssl_t also, or just leave it as convenience API if we wish. Affan: To answer your question, my intention would be to use this in messenger, but probably not expose it directly as messenger doesn't provide users direct control over or access to connections. Add support for SSL session resumption -- Key: PROTON-136 URL: https://issues.apache.org/jira/browse/PROTON-136 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.3 Reporter: Affan Dar Assignee: Ken Giusti Labels: ssl, sslContext, sslresume Open SSL supports resumption of SSL sessions which by-pass the heavy SSL handshake process. This is critical for scenarios involving low powered devices especially on cellular data networks where bandwidth is precious. It would be great if Proton exposes this ssl resume feature to users. . From: rhs [mailto:rschlom...@gmail.com] Sent: Tuesday, November 13, 2012 11:34 AM To: Affan Dar Cc: David Ingham Subject: Re: SSL session resumption On Tue, Nov 13, 2012 at 8:05 PM, Affan Dar affan...@microsoft.com wrote: Serializing/restoring the whole session state for the messenger will work for the scenario I think. Ok, let's start with this step then. I'm open to providing something finer grained if there is a need, but my preference is to keep it simple for the moment. One more thing, RFC 5077 has another flavor of session resumption which openssl supports (original implemented as RFC 4057 back in 2007 I think). This allows us to resume sessions without carrying state on the server side which as you can imagine is a big deal for service vendors. Probably there is no API level impact if messenger handles the session state itself but just wanted to put this on your radar. Ok, good to know. Could one of you file a JIRA for this upstream? I'm trying to get things a little more organized on the process front and keep everything centralized in JIRA. ;-) --Rafael -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-161) SSL impl does not allow verification of the peer's identity
[ https://issues.apache.org/jira/browse/PROTON-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504688#comment-13504688 ] Rafael H. Schloming commented on PROTON-161: What amount of plug-ability to you anticipate needing here? I'd like to be able to provide up front configuration to cover the majority of scenarios here, not only for convenience, but also because there's a significant technical obstacle to doing callbacks across language boundaries. Do you think wildcard matching would cover 90% of the cases? Are there significant other scenarios we could/should account for up front? SSL impl does not allow verification of the peer's identity --- Key: PROTON-161 URL: https://issues.apache.org/jira/browse/PROTON-161 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.3 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker The current SSL implementation validates the peer's certificate, and will not permit the connection to come up if the certificate is invalid. However - it does not provide a way to check if the peer's identity as provided in the certificate is the expected identity (eg, the same hostname used to set up the TCP connection). While a certificate may be valid (that is, signed by a CA trusted by the client), it may not belong to the intended destination. RFC2818 explains how this should be done - see section 3.1 Server Identity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-136) Add support for SSL session resumption
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504838#comment-13504838 ] Affan Dar commented on PROTON-136: -- Here is a scenario that might not work if the notion of ssl context is not exposed in the messenger API: + Client attempts to send a message to endpoint ep1 and as a result the SSL negotiation happens but at the end the server redirects it to endpoing ep2 + Client now needs to resend the same message to ep2 but wants to reuse the session id from above since If the session cache in the messenger api is keyed off of the endpoint name then this won't work. Also the knowledge that the session for ep1 should be reused for ep2 is very app specific. This is very handy in cases when i) the session cache is shared between a server farm OR ii) the server is redirecting to itself (e.g. to bypass a load balancer). Add support for SSL session resumption -- Key: PROTON-136 URL: https://issues.apache.org/jira/browse/PROTON-136 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.3 Reporter: Affan Dar Assignee: Ken Giusti Labels: ssl, sslContext, sslresume Open SSL supports resumption of SSL sessions which by-pass the heavy SSL handshake process. This is critical for scenarios involving low powered devices especially on cellular data networks where bandwidth is precious. It would be great if Proton exposes this ssl resume feature to users. . From: rhs [mailto:rschlom...@gmail.com] Sent: Tuesday, November 13, 2012 11:34 AM To: Affan Dar Cc: David Ingham Subject: Re: SSL session resumption On Tue, Nov 13, 2012 at 8:05 PM, Affan Dar affan...@microsoft.com wrote: Serializing/restoring the whole session state for the messenger will work for the scenario I think. Ok, let's start with this step then. I'm open to providing something finer grained if there is a need, but my preference is to keep it simple for the moment. One more thing, RFC 5077 has another flavor of session resumption which openssl supports (original implemented as RFC 4057 back in 2007 I think). This allows us to resume sessions without carrying state on the server side which as you can imagine is a big deal for service vendors. Probably there is no API level impact if messenger handles the session state itself but just wanted to put this on your radar. Ok, good to know. Could one of you file a JIRA for this upstream? I'm trying to get things a little more organized on the process front and keep everything centralized in JIRA. ;-) --Rafael -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-161) SSL impl does not allow verification of the peer's identity
[ https://issues.apache.org/jira/browse/PROTON-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504844#comment-13504844 ] Affan Dar commented on PROTON-161: -- I think that works fine. I.e, these three modes for hostname verification should cover most of the cases IMO: none, exact (subjectAltName or commonName must match the destination hostname) or custom (user provides hostname to match, hostname might contain wildcards). SSL impl does not allow verification of the peer's identity --- Key: PROTON-161 URL: https://issues.apache.org/jira/browse/PROTON-161 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.3 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker The current SSL implementation validates the peer's certificate, and will not permit the connection to come up if the certificate is invalid. However - it does not provide a way to check if the peer's identity as provided in the certificate is the expected identity (eg, the same hostname used to set up the TCP connection). While a certificate may be valid (that is, signed by a CA trusted by the client), it may not belong to the intended destination. RFC2818 explains how this should be done - see section 3.1 Server Identity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
New post regarding ApacheCon EU talk
Hi all, The ApacheCon EU presentation went very well as some of you may know. I have been meaning to post something on my blog but my site was taken down by hackers from a large country in Asia ;-) I did post this yesterday and hope to post something about the interop demo later. William
[jira] [Created] (PROTON-168) Support for building on OS X
Andy Goldstein created PROTON-168: - Summary: Support for building on OS X Key: PROTON-168 URL: https://issues.apache.org/jira/browse/PROTON-168 Project: Qpid Proton Issue Type: New Feature Components: proton-c Environment: Mac OS X Lion Reporter: Andy Goldstein Priority: Minor I did some quick hacky work to get proton-c to compile on my Mac running Lion. I also have homebrew installed and use that to supply any libraries that are necessary but not included by default on the Mac. I'm attaching my quick patch, and it would be great if someone could take it and update it so it's more robust and commit-quality :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-168) Support for building on OS X
[ https://issues.apache.org/jira/browse/PROTON-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated PROTON-168: -- Attachment: proton-168.patch Quick hacky patch to get proton to compile on OS X Lion Support for building on OS X Key: PROTON-168 URL: https://issues.apache.org/jira/browse/PROTON-168 Project: Qpid Proton Issue Type: New Feature Components: proton-c Environment: Mac OS X Lion Reporter: Andy Goldstein Priority: Minor Attachments: proton-168.patch I did some quick hacky work to get proton-c to compile on my Mac running Lion. I also have homebrew installed and use that to supply any libraries that are necessary but not included by default on the Mac. I'm attaching my quick patch, and it would be great if someone could take it and update it so it's more robust and commit-quality :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-168) Support for building on OS X
[ https://issues.apache.org/jira/browse/PROTON-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-168: - Attachment: PROTON-168-v2.patch Attaching a slightly updated version of the proton-168.patch so that cmake bits continue to work on Linux too. Support for building on OS X Key: PROTON-168 URL: https://issues.apache.org/jira/browse/PROTON-168 Project: Qpid Proton Issue Type: New Feature Components: proton-c Environment: Mac OS X Lion Reporter: Andy Goldstein Priority: Minor Attachments: proton-168.patch, PROTON-168-v2.patch I did some quick hacky work to get proton-c to compile on my Mac running Lion. I also have homebrew installed and use that to supply any libraries that are necessary but not included by default on the Mac. I'm attaching my quick patch, and it would be great if someone could take it and update it so it's more robust and commit-quality :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505243#comment-13505243 ] Affan Dar commented on PROTON-160: -- Regarding the messenger resolution process, the following semantic is one possibility and seems to reflect what you are thinking as well: - message.network_host, if specified, is the physical address of the host. I.e. this is the destination end point for the TCP connection. - message.address is the TLS endpoint of the host which is used in open.hostname and SASL etc. Furthermore, if message.network_host is not specified then this will also be used as the destination end point for the TCP connection, i.e. the easy default that you mentioned. - Messages with the same message.address can have different values in message.network_host and the connections associated with the respective networkhosts would be used to send these messages. I think PROTON-136 can benefit from this by using the message.address as the key for the session cache. Furthermore, are there plans on adding auto-redirect to the resolution process? I think it raises some other questions. If there is a JIRA tracking that work then I can add some comments to it. Allow open.hostname to be configured independently of network hostname -- Key: PROTON-160 URL: https://issues.apache.org/jira/browse/PROTON-160 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.1, 0.2 Reporter: David Ingham In a scaled-out, multi-tenant broker environment, the host on which the container is running is often different from the host to which a client is establishing the tcp connection. The 'hostname' field in the connection open performative was added to support this scenario. Currently there's no way to control this from the Messenger API. Options include: (1) (preferred) add a new 'networkhost' field to Message to allow the network address to be specified. If provided, this information would be used when establishing the network connection and the data in the 'address' field would be used in the connection open hostname field. This is somewhat in line with the way that connection redirect (amqp:connection:redirect) is specified. (2) extend the syntax of address with query string to supply hostname, e.g., username:password@tcpaddress:tcpport/entityname?hostname=foo where 'foo' would become the hostname used in the connection open frame. This is the approach used by the current Qpid AMQP 1.0 JMS client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
