[ANNOUNCE] Apache Qpid Python 1.37.0 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid Python 1.37.0. This release provides defect fixes for the AMQP 0-x Qpid Python client. The release is available now from our website: http://qpid.apache.org/download.html Release notes can be found at: http://qpid.apache.org/releases/qpid-python-1.37.0/release-notes.html Thanks to all involved, Robbie - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8054) [Broker-J] KeyStore type and algorithm defaults should be materialised on creation
[ https://issues.apache.org/jira/browse/QPID-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266104#comment-16266104 ] Rob Godfrey commented on QPID-8054: --- currently it appears that materialization (as implemented in QPID-7221) will only materialized on creation. Ideally this should be altered so that on open or update the attribute is also materialised to cover the cases of existing non-set values, or later unsetting of the value (not applicable in this case). > [Broker-J] KeyStore type and algorithm defaults should be materialised on > creation > -- > > Key: QPID-8054 > URL: https://issues.apache.org/jira/browse/QPID-8054 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Rob Godfrey > > Currently the keystore type and manager algorithm for FileKeyStore and > FileTrustStore are defaulted to JRE runtime defaults. If, for some reason, a > later execution of the broker has a differently configured JRE then the > values defaulted will not be in alignment with the actual configuration of > the key/trust store. As such the values for these attributes should be > materialized on creation. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8054) [Broker-J] KeyStore type and algorithm defaults should be materialised on creation
[ https://issues.apache.org/jira/browse/QPID-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266103#comment-16266103 ] ASF subversion and git services commented on QPID-8054: --- Commit 031e00611a8e2a682281ce617266c090d670a1d8 in qpid-broker-j's branch refs/heads/master from [~godfrer] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=031e006 ] QPID-8054 : [Broker-J] KeyStore type and algorithm defaults should be materialised on creation > [Broker-J] KeyStore type and algorithm defaults should be materialised on > creation > -- > > Key: QPID-8054 > URL: https://issues.apache.org/jira/browse/QPID-8054 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Rob Godfrey > > Currently the keystore type and manager algorithm for FileKeyStore and > FileTrustStore are defaulted to JRE runtime defaults. If, for some reason, a > later execution of the broker has a differently configured JRE then the > values defaulted will not be in alignment with the actual configuration of > the key/trust store. As such the values for these attributes should be > materialized on creation. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8054) [Broker-J] KeyStore type and algorithm defaults should be materialised on creation
Rob Godfrey created QPID-8054: - Summary: [Broker-J] KeyStore type and algorithm defaults should be materialised on creation Key: QPID-8054 URL: https://issues.apache.org/jira/browse/QPID-8054 Project: Qpid Issue Type: Bug Components: Broker-J Reporter: Rob Godfrey Currently the keystore type and manager algorithm for FileKeyStore and FileTrustStore are defaulted to JRE runtime defaults. If, for some reason, a later execution of the broker has a differently configured JRE then the values defaulted will not be in alignment with the actual configuration of the key/trust store. As such the values for these attributes should be materialized on creation. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8053) [Java Broker] Persistently associate (or otherwise authenticate) container ids with authenticated identity
Rob Godfrey created QPID-8053: - Summary: [Java Broker] Persistently associate (or otherwise authenticate) container ids with authenticated identity Key: QPID-8053 URL: https://issues.apache.org/jira/browse/QPID-8053 Project: Qpid Issue Type: Bug Components: Broker-J Reporter: Rob Godfrey In AMQP 1.0 durable links are identified by the combination of local and remote container (and direction). A connection identifying itself with a previously used container id can re-establish durable links, or steal non-durable links that were made on another connection. There is currently no mechanism associating the remote container-id with an identity meaning there is no validation that durable links are re-established (of existing links stolen) by the same actor who originally created them. While a connection has state associated with a container id, the broker should ensure that any other connection attempting to re-use the same container id is using the same identity. This means that the association should be persisted for durable links. It would also make sense to apply the same logic for mechanisms for durable subscriptions in earlier protocols -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8016) [Broker-J] FileKeyStore alias does not select the correct certificate
[
https://issues.apache.org/jira/browse/QPID-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266042#comment-16266042
]
Rob Godfrey commented on QPID-8016:
---
The update in QPID-7567 fixes this issue (while at the same time changing the
default so that unless specifically disabled the keystore will first look for a
cert which matches the SNI name. If no such cert is present, then it will
return the cert associated with the alias.
> [Broker-J] FileKeyStore alias does not select the correct certificate
> -
>
> Key: QPID-8016
> URL: https://issues.apache.org/jira/browse/QPID-8016
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>
> Keystore provider implementation {{FileKeyStore}} has a {{#certificateAlias}}
> attribute that is supposed to select a single certificate for use from a
> store that has many. This feature does not currently work. It seems that
> the last certificate is chosen regardless of the alias specified by the user.
> I reproduced this problem with test resource at
> {{test-profiles/test_resources/ssl/java_client_keystore.jks}}. It contains
> two non-CA certs app1 and app2. app2 was always presented over the TLS
> enabled socket, regardless of the setting of the {{certificateAlias}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7567) [Java Broker] Select appropriate certificate for TLS based on SNIServerName
[ https://issues.apache.org/jira/browse/QPID-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266037#comment-16266037 ] ASF subversion and git services commented on QPID-7567: --- Commit 09d7d8a19ed4e35d99c1b82e5e86aa135ea63c50 in qpid-broker-j's branch refs/heads/master from [~godfrer] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=09d7d8a ] QPID-7567 : Use SNI to select appropriate keystore alias > [Java Broker] Select appropriate certificate for TLS based on SNIServerName > --- > > Key: QPID-7567 > URL: https://issues.apache.org/jira/browse/QPID-7567 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall > Fix For: Future > > > Enable SNI support for the Java Broker. > We will need a X509ExtendedKeyManager implementation that gets the > SNIServerName from the SSL handshakes and then selects the most appropriate > certificate alias for the indicated hostname. > I found the following example helpful: > https://github.com/grahamedgecombe/netty-sni-example/blob/master/src/main/java/SniKeyManager.java > https://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html > This change requires Java 8, but it is probably possible to retain support > for Java 7 using reflection. > It looks to me like the clients (Qpid JMS Client and Legacy) require no > changes. They both pass the hostname through to the SSLEngine, so the > SNIServerName should already be passed through. Client side support in Java > was added at Java 7. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8032) [AMQP1.0] AsyncAutoCommitTransaction optimisation
[
https://issues.apache.org/jira/browse/QPID-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8032:
-
Fix Version/s: (was: Future)
qpid-java-broker-7.0.1
> [AMQP1.0] AsyncAutoCommitTransaction optimisation
> -
>
> Key: QPID-8032
> URL: https://issues.apache.org/jira/browse/QPID-8032
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.1
>
>
> Some AMQP 1.0 messaging use-cases would benefit from the
> {{AsyncAutoCommitTransactions}} optimisation that is already in use on the
> older protocols.
> For instance, for a publisher sending persistent settled messages, currently
> each message is written to disk and sync before the next message is the
> buffer is processed,. With this optimisation, the syncs would be allowed to
> coalesce.
> Care needs to be taken when the work includes actions that aren't
> non-transactional transfers to ensure that transactions remain ACID.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-327) QPid JMS has no support for the content-type AMQP properties
[
https://issues.apache.org/jira/browse/QPIDJMS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266010#comment-16266010
]
Kai Hudalla commented on QPIDJMS-327:
-
Going through the latest docs published by the OASIS Advanced Message Queuing
Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC on this subject, my
understanding is that the vendor property is (or will be)
{{JMS_AMQP_CONTENT_TYPE}}. However, the current QPID JMS Client 0.27 still
doesn't seem to support it, i.e. incoming messages do not have a String
property of that name which can be accessed via
{{javax.jms.Message.getStringProperty()}} and {{Message.getPropertyNames()}}
also doesn't seem to contain the property :-(
Is there any compelling reason why the content type is not (yet) mapped as
proposed in the JMS Binding document? I know that it hasn't been released yet.
However, FMPOV using the JMS client to interact with AMQP 1.0 infrastructure is
almost useless without a way to get/set the content-type.
> QPid JMS has no support for the content-type AMQP properties
>
>
> Key: QPIDJMS-327
> URL: https://issues.apache.org/jira/browse/QPIDJMS-327
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Leo Riguspi
>
> The content-type AMQP property cannot be set. According to the specifications
> it should be set via the Jms property JMS_AMQP_ContentType, however this
> results in nothing being set.
> NOTE: there is a similar issue (albeit different) for the content-encoding
> property (see [https://issues.apache.org/jira/browse/QPIDJMS-295])
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
