June 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2275) ASYM_ENCRYPT: encrypt join response

by Bela Ban (JIRA)

Bela Ban created JGRP-2275: ------------------------------ Summary: ASYM_ENCRYPT: encrypt join response Key: JGRP-2275 URL: https://issues.jboss.org/browse/JGRP-2275 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0.12 In {{ASYM_ENCRYPT}}, when a new member joins, it sends a JOIN-REQ to the coordinator (unencrypted, as it does not yet have the secret key). The coordinator skips decryption, creates a JOIN-RSP, and sends it to the joiner *unencrypted*. The reason is that the joiner doesn't yet have the secret key, so it couldn't possibly decrypt the JOIN-RSP and install the view. (This is btw not a security issue as subsequent messages *are* encrypted and a rogue member would not be able to decrypt them. However, a rogue member would be able to join the cluster. To prevent this, the JOIN-RSP sent by the coordinator to the joiner will be encrypted. The joiner will not be able to decrypt it and simply drops it, but it also asks the keyserver (coord) for the secret key. Once the secret key has been received, the (retransmitted) JOIN-RSP will be received, decrypted with the received secret key and the view can be installed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs

by Bela Ban (JIRA)

Bela Ban created JGRP-2274: ------------------------------ Summary: ASYM_ENCRYPT: deprecate sign_msgs Key: JGRP-2274 URL: https://issues.jboss.org/browse/JGRP-2274 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0.12 In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature. However, this is redundant, as decryption of a message will fail if the contents have been changed. If needed, signing of messages can be done in a separate protocol. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2273) ASYM_ENCRYPT: deprecate encrypt_entire_message

by Bela Ban (JIRA)

Bela Ban created JGRP-2273: ------------------------------ Summary: ASYM_ENCRYPT: deprecate encrypt_entire_message Key: JGRP-2273 URL: https://issues.jboss.org/browse/JGRP-2273 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0.12 In {{ASYM_ENCRYPT}}, {{encrypt_entire_message}} encrypts not only the payload, but also metadata such as destination and sender's address, headers and flags. The rationale was to prevent replay attacks. However, this is not an issue, as replayed messages will simply get dropped by the retransmission layer (e.g. NAKACK2 or UNICAST3). If people still want this feature, they can write a protocol _above_ {{ASYM_ENCRYPT}}, which serializes the entire message into the payload of a new message, and this would be exactly the same as setting {{encrypt_entire_message}} to {{true}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3902) Support Maven staged repositories

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3902?page=com.atlassian.jira.plugi... ] Jeff Mesnil resolved WFCORE-3902. --------------------------------- Fix Version/s: 6.0.0.Alpha1 Resolution: Done > Support Maven staged repositories > --------------------------------- > > Key: WFCORE-3902 > URL: https://issues.jboss.org/browse/WFCORE-3902 > Project: WildFly Core > Issue Type: Task > Components: Build System > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 6.0.0.Alpha1 > > > When WildFly Core is released, one of the step is to check that the Core releases can be downloaded from Nexus repositories to build WildFly. > However that step requires to release WildFly Core artifacts. If something went wrong, the release is out and there is nothing we can do except moving to the next release and restart the whole process. > We should instead ensure that WildFly can access Nexus staging repositories so that we can verify that WildFly can download and uses the Core artifcats before they are actually released. > If something goes wrong, we can redo the tag without any issue. > This simplifies the release of WildFly core: > 1. the Core release is created as usual. > 2. WildFly consumes the artifacts from the staging repository > 3. If everything is fine, the last steps for Core releases are the Git tag and the actual release from the staging repository. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3900) Bump the kernel management API version to 8.0.0 and the xsd to 8.0

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3900?page=com.atlassian.jira.plugi... ] Jeff Mesnil resolved WFCORE-3900. --------------------------------- Resolution: Done > Bump the kernel management API version to 8.0.0 and the xsd to 8.0 > ------------------------------------------------------------------ > > Key: WFCORE-3900 > URL: https://issues.jboss.org/browse/WFCORE-3900 > Project: WildFly Core > Issue Type: Task > Components: Management > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Fix For: 6.0.0.Alpha1 > > > We know there are going to be API changes in WF Core 6, so we need to get the API version bumped so that when those changes happen appropriate transformers can be written to transform to the previous version. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10513) Getting JTA Datasource (Wildfly 13)

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-10513?page=com.atlassian.jira.plugin... ] Martin Kouba updated WFLY-10513: -------------------------------- Component/s: (was: CDI / Weld) > Getting JTA Datasource (Wildfly 13) > ----------------------------------- > > Key: WFLY-10513 > URL: https://issues.jboss.org/browse/WFLY-10513 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 13.0.0.Final > Reporter: David Tierens > Assignee: Martin Kouba > Priority: Minor > > In Wildfly 12 it ,was possible to get the DataSource via : > > {code:java} > @ApplicationScoped > public class ExamplePersistenceContextConfiguration { > > @PersistenceContext(unitName = "examplePersistenceUnit") > @Produces > private EntityManager entityManager; > > @Produces > public DataSource getDataSource() { > EntityManagerFactory entityManagerFactory = entityManager.getEntityManagerFactory(); > Map<String, Object> properties = entityManagerFactory.getProperties(); > return (DataSource) properties.get("javax.persistence.jtaDataSource"); > } > > @Produces > public SessionFactory getSessionFactory() { > Session session = entityManager.unwrap(Session.class); > return session.getSessionFactory(); > } > } > {code} > > Currently it's returning null in Wildfly 13, however : > {code:java} > (DataSource) properties.get("hibernate.connection.datasource"); > {code} > does work (instead of : > {code:java} > (DataSource) properties.get("javax.persistence.jtaDataSource") > {code} > > Persistence.XML : > {code:xml} > // Some comments here > public String getFoo() > { > return foo; > } > <?xml version="1.0" encoding="UTF-8"?> > <persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence > http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd" > version="2.1"> >  > <persistence-unit name="examplePersistenceUnit" transaction-type="JTA"> > <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider> > <jta-data-source>jdbc/ExampleXADataSource</jta-data-source> > <properties> > <property name="hibernate.dialect" value="org.hibernate.dialect.Oracle10gDialect"/> > <property name="hibernate.show_sql" value="true"/> > <property name="hibernate.order_inserts" value="true"/> > <property name="hibernate.jdbc.wrap_result_sets" value="true"/> > <property name="hibernate.integration.envers.enabled" value="false"/> > </properties> > </persistence-unit> > </persistence> > {code} > > Is there any way to get it via the properties.get("javax.persistence.jtaDataSource") and not via Hibernate ? > > Thanks in advance, > David -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2272) ASYM_ENCRYPT: remove queuing

by Bela Ban (JIRA)

Bela Ban created JGRP-2272: ------------------------------ Summary: ASYM_ENCRYPT: remove queuing Key: JGRP-2272 URL: https://issues.jboss.org/browse/JGRP-2272 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0.12 When the secret key has not yet been received in {{ASYM_ENCRYPT}}, messages received from other members are queued until the secret key has been received, and then drained. This leads to _unneeded complexity_ and is actually not needed: when a member joins or merges, it gets a JOIN_RSP or INSTALL_MERGE_VIEW unicast message, which can safely be dropped as they're retransmitted. So, instead of queuing messages when the secret key has not yet been received, we simply drop them. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10513) Getting JTA Datasource (Wildfly 13)

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-10513?page=com.atlassian.jira.plugin... ] Martin Kouba reassigned WFLY-10513: ----------------------------------- Assignee: Scott Marlow (was: Martin Kouba) > Getting JTA Datasource (Wildfly 13) > ----------------------------------- > > Key: WFLY-10513 > URL: https://issues.jboss.org/browse/WFLY-10513 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 13.0.0.Final > Reporter: David Tierens > Assignee: Scott Marlow > Priority: Minor > > In Wildfly 12 it ,was possible to get the DataSource via : > > {code:java} > @ApplicationScoped > public class ExamplePersistenceContextConfiguration { > > @PersistenceContext(unitName = "examplePersistenceUnit") > @Produces > private EntityManager entityManager; > > @Produces > public DataSource getDataSource() { > EntityManagerFactory entityManagerFactory = entityManager.getEntityManagerFactory(); > Map<String, Object> properties = entityManagerFactory.getProperties(); > return (DataSource) properties.get("javax.persistence.jtaDataSource"); > } > > @Produces > public SessionFactory getSessionFactory() { > Session session = entityManager.unwrap(Session.class); > return session.getSessionFactory(); > } > } > {code} > > Currently it's returning null in Wildfly 13, however : > {code:java} > (DataSource) properties.get("hibernate.connection.datasource"); > {code} > does work (instead of : > {code:java} > (DataSource) properties.get("javax.persistence.jtaDataSource") > {code} > > Persistence.XML : > {code:xml} > // Some comments here > public String getFoo() > { > return foo; > } > <?xml version="1.0" encoding="UTF-8"?> > <persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence > http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd" > version="2.1"> >  > <persistence-unit name="examplePersistenceUnit" transaction-type="JTA"> > <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider> > <jta-data-source>jdbc/ExampleXADataSource</jta-data-source> > <properties> > <property name="hibernate.dialect" value="org.hibernate.dialect.Oracle10gDialect"/> > <property name="hibernate.show_sql" value="true"/> > <property name="hibernate.order_inserts" value="true"/> > <property name="hibernate.jdbc.wrap_result_sets" value="true"/> > <property name="hibernate.integration.envers.enabled" value="false"/> > </properties> > </persistence-unit> > </persistence> > {code} > > Is there any way to get it via the properties.get("javax.persistence.jtaDataSource") and not via Hibernate ? > > Thanks in advance, > David -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2616) Executable model - DRL integration tests fail with the model

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2616: ----------------------------------- Summary: Executable model - DRL integration tests fail with the model Key: DROOLS-2616 URL: https://issues.jboss.org/browse/DROOLS-2616 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.7.0.Final Reporter: Tibor Zimányi Assignee: Mario Fusco When running DRL integration tests [1] with the executable model, 118 out of 510 test cases fail. PR with tests is here [2]. [1] https://github.com/kiegroup/drools/tree/master/drools-compiler/src/test/j... [2] https://github.com/kiegroup/drools/pull/1915 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2615) Executable model - tests from package "integrationtests.operators" fail when run with executable model

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2615: ----------------------------------- Summary: Executable model - tests from package "integrationtests.operators" fail when run with executable model Key: DROOLS-2615 URL: https://issues.jboss.org/browse/DROOLS-2615 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.7.0.Final Reporter: Tibor Zimányi Assignee: Luca Molteni When running tests from package org.drools.compiler.integrationtests.operators [1] with executable model, many of them fail (~120 out of ~520). To run the tests with the model, I moved the tests to a separate module in this PR [2], please check the PR description to see how to run them. [1] https://github.com/kiegroup/drools/tree/d7ad4fb31647b5295c3cbc0321f0d8f89... [2] https://github.com/kiegroup/drools/pull/1901 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2018