February 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3947) Support SSL Certificate revocation using OCSP

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-3947?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-3947: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.0.0.CR1) > Support SSL Certificate revocation using OCSP > --------------------------------------------- > > Key: WFCORE-3947 > URL: https://issues.jboss.org/browse/WFCORE-3947 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Affects Versions: 6.0.0.Alpha2 > Reporter: Jan Kalina > Assignee: Martin Mazanek > Priority: Major > Fix For: 9.0.0.Beta1 > > > - Provide undertow's client certificate revocation capability when undertow is used as a load balancer using OCSP. > (CRL capability is provided in the earlier release as part of Elytron SSL Consolidation effort that this JIRA is cloned from) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3983) Update the WildFly Elytron Subsystem to use the new MSC Service API

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-3983?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-3983: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.0.0.CR1) > Update the WildFly Elytron Subsystem to use the new MSC Service API > ------------------------------------------------------------------- > > Key: WFCORE-3983 > URL: https://issues.jboss.org/browse/WFCORE-3983 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.Beta1 > > > At some point we want to consider breaking the subsystem into smaller chunks to allow a more selective subset of functionality to be selected - before we do that it would be good to clean up the general approach in the subsystem. We have trivial resources and services within the subsystem but the new MSC APIs may simpify a lot of this. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4150) Support automatically adding / updating credentials in the CredentialStore

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4150?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4150: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.0.0.CR1) > Support automatically adding / updating credentials in the CredentialStore > -------------------------------------------------------------------------- > > Key: WFCORE-4150 > URL: https://issues.jboss.org/browse/WFCORE-4150 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4172) Add support for TLS 1.3

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4172?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4172: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.0.0.CR1) > Add support for TLS 1.3 > ----------------------- > > Key: WFCORE-4172 > URL: https://issues.jboss.org/browse/WFCORE-4172 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Labels: eap-7.2.0-deferred > Fix For: 9.0.0.Beta1 > > > It presently appears as though TLS 1.3 support could be available from Java 11. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4259) Upgrade WildFly Elytron to 1.8.x

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4259?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4259: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.0.0.CR1) > Upgrade WildFly Elytron to 1.8.x > -------------------------------- > > Key: WFCORE-4259 > URL: https://issues.jboss.org/browse/WFCORE-4259 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4261) Update Maven dependencies to reference individual Elytron modules.

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4261?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4261: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.0.0.CR1) > Update Maven dependencies to reference individual Elytron modules. > ------------------------------------------------------------------ > > Key: WFCORE-4261 > URL: https://issues.jboss.org/browse/WFCORE-4261 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.Beta1 > > > Additionally remove the root 'wildfly-elytron' dependency. > This should also review the classes the application server users as we will likely want to start considering these public API. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4282) Remove use of java.security.acl APIs in Elytron PolicyDefinitions

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4282?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4282: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.0.0.CR1) > Remove use of java.security.acl APIs in Elytron PolicyDefinitions > ----------------------------------------------------------------- > > Key: WFCORE-4282 > URL: https://issues.jboss.org/browse/WFCORE-4282 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Priority: Critical > Labels: Java13 > Fix For: 9.0.0.Beta1 > > > The 'java.security.acls' packages has been deprecated and flagged for removal, this will be removed in Java 13 > https://bugs.openjdk.java.net/browse/JDK-8191138 > Within the Elytron subsystem we are presently using it within the PolicyDefinitions / Subject conversion likely to maintain compatibility with prior PicketBox implementations. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3702) [Stunner] Arrows are incorrectly positioned when save-open diagram

by Roger Martínez (Jira)

[ https://issues.jboss.org/browse/DROOLS-3702?page=com.atlassian.jira.plugi... ] Roger Martínez updated DROOLS-3702: ----------------------------------- Labels: Stunner (was: ) > [Stunner] Arrows are incorrectly positioned when save-open diagram > ------------------------------------------------------------------ > > Key: DROOLS-3702 > URL: https://issues.jboss.org/browse/DROOLS-3702 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Daniel José dos Santos > Assignee: Roger Martínez > Priority: Major > Labels: Stunner > Attachments: weird_arrow.gif > > > 1. Add a `Decision Node` > 2. Add a `Input Data Node` bellow `Decision Node` > 3. Connect `Input Data Node` to `Decision Node` > 4. Save > 5. Close > 6. Open againThe arrow from `Input Data Node` to `Decision Node` will be at right of the `Decision Node` and if you move the `Input Data Node`, the arrow is not repositioned. > I noticed this in DMN Showcase and in drools-wb. > And if you add a new `Decision Node` and a new `Input Data Node`, without save and close, it behaves as expected. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3702) [Stunner] Arrows are incorrectly positioned when save-open diagram

by Roger Martínez (Jira)

[ https://issues.jboss.org/browse/DROOLS-3702?page=com.atlassian.jira.plugi... ] Roger Martínez updated DROOLS-3702: ----------------------------------- Component/s: DMN Editor > [Stunner] Arrows are incorrectly positioned when save-open diagram > ------------------------------------------------------------------ > > Key: DROOLS-3702 > URL: https://issues.jboss.org/browse/DROOLS-3702 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Daniel José dos Santos > Assignee: Roger Martínez > Priority: Major > Labels: Stunner > Attachments: weird_arrow.gif > > > 1. Add a `Decision Node` > 2. Add a `Input Data Node` bellow `Decision Node` > 3. Connect `Input Data Node` to `Decision Node` > 4. Save > 5. Close > 6. Open againThe arrow from `Input Data Node` to `Decision Node` will be at right of the `Decision Node` and if you move the `Input Data Node`, the arrow is not repositioned. > I noticed this in DMN Showcase and in drools-wb. > And if you add a new `Decision Node` and a new `Input Data Node`, without save and close, it behaves as expected. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11750) Allow cluster to use DNS addresses instead of IP addresses

by Tomasz Adamski (Jira)

[ https://issues.jboss.org/browse/WFLY-11750?page=com.atlassian.jira.plugin... ] Tomasz Adamski edited comment on WFLY-11750 at 2/25/19 3:41 PM: ---------------------------------------------------------------- [~pferraro] But if I understand correctly HA features and correct transaction recovery are independent. Let's suppose we are on bare-metal and have a cluster of n nodes. At some point, one of the nodes is invoked by the client, takes part in the transaction with two-phase commit and after prepare stage the node fails. As a result, the client has a record in its permanent object store and tries to finish the transaction. As the record contains the IP address of the failed node the client will wait till the server is up again to finish the transaction. That node will have the new cluster identity. My understanding is that it has no effect on transaction recovery which will work fine. On the other hand, OpenShift does not guarantee the IP node identity - only DNS identity - so IMO the cluster will work fine but recovery won't. But the key thing here IMO is, the way remoting gets node information. When clustering is involved it gets raw IP addresses which won't work fine on OpenShift and my thought was that the simplest solution would be to use DNS addresses as base for cluster operation. === Another thing: does clustering takes care of replicating Narayana object store? If this is the case then the problem would be different. was (Author: tomekadamski): [~pferraro] But if I understand correctly HA features and correct transaction recovery are independent. Let's suppose we are on bare-metal and have a cluster of n nodes. At some point, one of the nodes is invoked by the client, takes part in the transaction with two-phase commit and after prepare stage the node fails. As a result, the client has a record in its permanent object store and tries to finish the transaction. As the record contains the IP address of the failed node the client will wait till the server is up again to finish the transaction. That node will have the new cluster identity. My understanding is that it has no effect on transaction recovery which will work fine. On the other hand, OpenShift does not guarantee the IP node identity - only DNS identity - so IMO the cluster will work fine but recovery won't. But the key thing here IMO is, the way remoting gets node information. When clustering is involved it gets raw IP addresses which won't work fine on OpenShift and my thought was that the simplest solution would be to use DNS addresses as base for cluster operation. > Allow cluster to use DNS addresses instead of IP addresses > ---------------------------------------------------------- > > Key: WFLY-11750 > URL: https://issues.jboss.org/browse/WFLY-11750 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 16.0.0.Beta1 > Reporter: Tomasz Adamski > Assignee: Paul Ferraro > Priority: Major > > We would need a configuration that would allow for the cluster to use DNS addresses instead of IP addresses. The reason is that OpenShift guarantees the node identity under DNS address and not under IP address. > Sample scenario that may currently fail when application are deployed in OpenShift: > A (application) > B (clustered application) > 1. A calls transactional invocation on B > 2. as a result of discovery process A obtains a cluster topology from B and uses one of obtained IP addresses for the connection > 3. as the invocation is transactional the object-store records are written in A's persistent object store; those records are based on the data obtained from the cluster => subordinate node is identified by the IP address from point two > 4. B node fails > 5. OpenShift restarts node B on another IP address > 6. A attempts recovery and persistently fails > OTOH OpenShift guarantees node identity under DNS address. As a result, at point 5 node is guaranteed to restart on established DNS address so if the cluster used this address instead of physical addresses the scenario above will finish with A being able to recover the transaction. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

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 February 2019