February 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-944?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-944: ------------------------------------ Fix Version/s: (was: 11.0.0.Beta9) > truststore path is ignored if provider is not JKS > ------------------------------------------------- > > Key: WFCORE-944 > URL: https://issues.redhat.com/browse/WFCORE-944 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Arto Huusko > Priority: Major > > truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS. > This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working. > We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured. > Even standard java supports PKCS12 truststores, where the same problem would occur. > So I would suggest that > - if provider is JKS, path is mandatory > - if provider is not JKS, but path is specified, it is passed to the provider -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11939) FineDatabasePersistenceWebFailoverTestCase fails intermittently

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/WFLY-11939?page=com.atlassian.jira.plugi... ] Thomas Jenkinson commented on WFLY-11939: ----------------------------------------- I am not sure if this is the same issue, but we observed a failure on Narayana CI from a test in the same suite after the fixVersion that this was marked for. Our CI script rebases the fork we use for testing and so I think the commits we would have been running from WildFly would be as of https://github.com/wildfly/wildfly/tree/65d364f1435258428d945094e77b6eb4b... The failure was: {code}FineDatabasePersistenceWebFailoverTestCase>AbstractWebFailoverTestCase.test:87->AbstractWebFailoverTestCase.testGracefulUndeployFailover:96->AbstractWebFailoverTestCase.testFailover:104->AbstractWebFailoverTestCase.establishTopology:389 expected:<200> but was:<500>{code} The console output: http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/563/PROFILE=AS_TE... More data: http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/563/PROFILE=AS_TE... and http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/563/PROFILE=AS_TE... [~pferraro] would you like a new issue to be created or could it be the same as and a recurrence of this issue? > FineDatabasePersistenceWebFailoverTestCase fails intermittently > --------------------------------------------------------------- > > Key: WFLY-11939 > URL: https://issues.redhat.com/browse/WFLY-11939 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: No Release > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > Fix For: 17.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13062) Upgrade WildFly Core 11.0.0.Beta9

by Jeff Mesnil (Jira)

Jeff Mesnil created WFLY-13062: ---------------------------------- Summary: Upgrade WildFly Core 11.0.0.Beta9 Key: WFLY-13062 URL: https://issues.redhat.com/browse/WFLY-13062 Project: WildFly Issue Type: Component Upgrade Components: Management Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 19.0.0.Beta2 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13062) Upgrade WildFly Core 11.0.0.Beta8

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13062?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFLY-13062: ------------------------------- Summary: Upgrade WildFly Core 11.0.0.Beta8 (was: Upgrade WildFly Core 11.0.0.Beta9) > Upgrade WildFly Core 11.0.0.Beta8 > --------------------------------- > > Key: WFLY-13062 > URL: https://issues.redhat.com/browse/WFLY-13062 > Project: WildFly > Issue Type: Component Upgrade > Components: Management > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Major > Fix For: 19.0.0.Beta2 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4484) Support SSH authentication for Git persistence

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4484?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4484: -------------------------------- Fix Version/s: 11.0.0.Beta9 (was: 11.0.0.Beta8) > Support SSH authentication for Git persistence > ---------------------------------------------- > > Key: WFCORE-4484 > URL: https://issues.redhat.com/browse/WFCORE-4484 > Project: WildFly Core > Issue Type: Feature Request > Components: Management, Security > Reporter: Farah Juma > Assignee: Ashley Abdel-Sayed > Priority: Major > Labels: EAP-CD19 > Fix For: 11.0.0.Beta9 > > > Currently Elytron only supports authentication for HTTP(s) URLS so there is no way to connect to a SSH git server to pull/push configuration history -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4482) Out of the box SSL with Wildfly Elytron

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4482?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4482: -------------------------------- Fix Version/s: 11.0.0.Beta9 (was: 11.0.0.Beta8) > Out of the box SSL with Wildfly Elytron > --------------------------------------- > > Key: WFCORE-4482 > URL: https://issues.redhat.com/browse/WFCORE-4482 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Labels: EAP-CD19 > Fix For: 11.0.0.Beta9 > > > The details of this RFE will be explored within the analysis, presently Undertow depends on a security-realm that generates a self signed cert on start up so we will require an Elytron equivalent. > There may be opportunities to tie this in in some way with the new CA integration support but that can be explored in the analysis. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3376) Modules may create loggers on a deployments log context

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-3376?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-3376: -------------------------------- Fix Version/s: 11.0.0.Beta9 (was: 11.0.0.Beta8) > Modules may create loggers on a deployments log context > ------------------------------------------------------- > > Key: WFCORE-3376 > URL: https://issues.redhat.com/browse/WFCORE-3376 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Fix For: 11.0.0.Beta9 > > > Currently WildFly uses a {{ClassLoaderLogContextSelector}} to determine the log context to use when creating loggers. If a deployment has it's own log context, via logging-profile or per-deployment logging, and a dependency on a module, that module may create loggers on the deployments log context. This is due to the fact the the call stack is walked until it finds a log context associated with a class loader. > What is needed is a way to short-circuit once a non-logging API class loader is found and determine if there is an associated log context with the callers class loader. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-944?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-944: ------------------------------- Fix Version/s: 11.0.0.Beta9 (was: 11.0.0.Beta8) > truststore path is ignored if provider is not JKS > ------------------------------------------------- > > Key: WFCORE-944 > URL: https://issues.redhat.com/browse/WFCORE-944 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Arto Huusko > Priority: Major > Fix For: 11.0.0.Beta9 > > > truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS. > This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working. > We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured. > Even standard java supports PKCS12 truststores, where the same problem would occur. > So I would suggest that > - if provider is JKS, path is mandatory > - if provider is not JKS, but path is specified, it is passed to the provider -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4822) Upgrade Management API Version to 12.0

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4822?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4822: -------------------------------- Fix Version/s: 11.0.0.Beta9 (was: 11.0.0.Beta8) > Upgrade Management API Version to 12.0 > -------------------------------------- > > Key: WFCORE-4822 > URL: https://issues.redhat.com/browse/WFCORE-4822 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Jeff Mesnil > Assignee: Yeray Borges > Priority: Blocker > Fix For: 11.0.0.Beta9 > > > We need to fix the version state before WildFly 19 is released. > * The KernelAPIVersion must be bumped to 12.0 > * We also need to release wildly-config-12.0.xsd with the proper host-exclude for > * WildFlY18, Version.10 > * EAP73, Version.10 > (and add those to KnownRelease too) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4485) Support for multiple security realms - Distributed Identities

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4485?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4485: -------------------------------- Fix Version/s: 11.0.0.Beta9 (was: 11.0.0.Beta8) > Support for multiple security realms - Distributed Identities > ------------------------------------------------------------- > > Key: WFCORE-4485 > URL: https://issues.redhat.com/browse/WFCORE-4485 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Priority: Major > Labels: CD17-Deferred, EAP-CD19, Previous_RFE > Fix For: 11.0.0.Beta9 > > > By stacking LoginModules it was possible using PicketBox to attempt to authenticate using one remote store and if that failed try the next store in the list. > This RFE is to consider the use case where identities could be located across multiple stores and how they are aggregated together. > Additionally this use case should consider how the authorization information could be loaded from multiple sources and merged. > This RFE is not about fail over in the event of a realm being unavailable although it may be related. > This RFE is created as a result of comparing the differences between the PicketBox JAAS architecture and the Elytron architecture so I would not recommend this proceeds without some real world use cases identified. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 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 2020