August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3133) [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory?

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3133?page=com.atlassian.jira.plugi... ] Jiri Ondrusek updated WFCORE-3133: ---------------------------------- Description: Part of solution for: https://issues.jboss.org/browse/WFLY-9155. Server has to be able to start after such migration -> with empty keystore password. --- In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password. Does it really make sense to require it? In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation? was: In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password. Does it really make sense to require it? In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation? Server has to be able to start after such migration -> with empty keystore password. > [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory? > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-3133 > URL: https://issues.jboss.org/browse/WFCORE-3133 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 3.0.0.Beta30 > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > > Part of solution for: https://issues.jboss.org/browse/WFLY-9155. > Server has to be able to start after such migration -> with empty keystore password. > --- > In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password. > Does it really make sense to require it? > In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9155) [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory?

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/WFLY-9155?page=com.atlassian.jira.plugin.... ] Jiri Ondrusek updated WFLY-9155: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/10381 (was: https://github.com/wildfly/wildfly/pull/10381, https://github.com/wildfly/wildfly-core/pull/2680) > [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory? > ------------------------------------------------------------------------------------------------------------ > > Key: WFLY-9155 > URL: https://issues.jboss.org/browse/WFLY-9155 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Beta1 > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > > In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password. > Does it really make sense to require it? > In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3133) [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory?

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3133?page=com.atlassian.jira.plugi... ] Jiri Ondrusek updated WFCORE-3133: ---------------------------------- Description: In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password. Does it really make sense to require it? In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation? Server has to be able to start after such migration -> with empty keystore password. was: In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password. Does it really make sense to require it? In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation? > [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory? > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-3133 > URL: https://issues.jboss.org/browse/WFCORE-3133 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 3.0.0.Beta30 > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > > In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password. > Does it really make sense to require it? > In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation? > Server has to be able to start after such migration -> with empty keystore password. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3133) [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory?

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3133?page=com.atlassian.jira.plugi... ] Jiri Ondrusek moved JBEAP-12480 to WFCORE-3133: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-3133 (was: JBEAP-12480) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: Migration) (was: Web (Undertow)) Affects Version/s: 3.0.0.Beta30 (was: 7.0.0.DR9) > [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory? > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-3133 > URL: https://issues.jboss.org/browse/WFCORE-3133 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 3.0.0.Beta30 > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > > In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password. > Does it really make sense to require it? > In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5413) On IIOP migration default properties are not persisted

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.... ] Jason Greene resolved WFLY-5413. -------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.CR1) Resolution: Done > On IIOP migration default properties are not persisted > ------------------------------------------------------ > > Key: WFLY-5413 > URL: https://issues.jboss.org/browse/WFLY-5413 > Project: WildFly > Issue Type: Enhancement > Components: IIOP > Affects Versions: 10.0.0.CR1 > Reporter: Ondra Chaloupka > Assignee: Tomasz Adamski > Fix For: 11.0.0.Beta1 > > > If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML. > It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly. > The example of such properties which do not persist because of its default values are > * initializers: security="none" > * security: client-supports="ServerAuth" server-supports="MutualAuth" > * security: client-requires="None" server-requires="None" > * transport-config: detect-misordering="none" > * as-context: auth-method="username_password" required="false" > * sas-context caller-propagation="none" > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5413) On IIOP migration default properties are not persisted

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.... ] Jason Greene reopened WFLY-5413: -------------------------------- reopening to change fix version > On IIOP migration default properties are not persisted > ------------------------------------------------------ > > Key: WFLY-5413 > URL: https://issues.jboss.org/browse/WFLY-5413 > Project: WildFly > Issue Type: Enhancement > Components: IIOP > Affects Versions: 10.0.0.CR1 > Reporter: Ondra Chaloupka > Assignee: Tomasz Adamski > Fix For: 11.0.0.Beta1 > > > If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML. > It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly. > The example of such properties which do not persist because of its default values are > * initializers: security="none" > * security: client-supports="ServerAuth" server-supports="MutualAuth" > * security: client-requires="None" server-requires="None" > * transport-config: detect-misordering="none" > * as-context: auth-method="username_password" required="false" > * sas-context caller-propagation="none" > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3132) Creation of RedirectHandler results in Undertow predicate parser being initialised on server boot

by Stuart Douglas (JIRA)

Stuart Douglas created WFCORE-3132: -------------------------------------- Summary: Creation of RedirectHandler results in Undertow predicate parser being initialised on server boot Key: WFCORE-3132 URL: https://issues.jboss.org/browse/WFCORE-3132 Project: WildFly Core Issue Type: Bug Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1294) Wildfly Elytron Tool, Credential-store command, --salt option is validated only when --summary is used too.

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/ELY-1294?page=com.atlassian.jira.plugin.s... ] Chao Wang reopened ELY-1294: ---------------------------- > Wildfly Elytron Tool, Credential-store command, --salt option is validated only when --summary is used too. > ----------------------------------------------------------------------------------------------------------- > > Key: ELY-1294 > URL: https://issues.jboss.org/browse/ELY-1294 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Chao Wang > > Credential-store command \-\-salt option is validated only when is \-\-summary is used too. > It is caused by generation MASKed password for summary output[1]. > It is at least strange and confusing to user: without \-\-summary is passed, with \-\-summary is failed (entry is stored in storage successfully). > *How to reproduce* > {code} > [hsvabek@dhcp-10-40-5-17 bin]$ ./elytron-tool.sh credential-store --add secret_alias --password pass123 --create -x secret_password -l store005.jceks -s 1234567890 -i 230 --summary --debug > Alias "secret_alias" has been successfully stored > Exception encountered executing the command: > java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long > at com.sun.crypto.provider.PBES1Core.init(PBES1Core.java:234) > at com.sun.crypto.provider.PBES1Core.init(PBES1Core.java:331) > at com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineInit(PBEWithMD5AndDESCipher.java:228) > at javax.crypto.Cipher.implInit(Cipher.java:810) > at javax.crypto.Cipher.chooseProvider(Cipher.java:864) > at javax.crypto.Cipher.init(Cipher.java:1539) > at javax.crypto.Cipher.init(Cipher.java:1470) > at org.wildfly.security.util.PasswordBasedEncryptionUtil$Builder.createAndInitCipher(PasswordBasedEncryptionUtil.java:506) > at org.wildfly.security.util.PasswordBasedEncryptionUtil$Builder.build(PasswordBasedEncryptionUtil.java:589) > at org.wildfly.security.tool.MaskCommand.computeMasked(MaskCommand.java:117) > at org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:287) > at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:81) > {code} > [1] https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.CR2/s... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9158) Provider com.sun.deploy.security.MozillaJSSProvider could not be instantiated when running the secman integration tests with JDK-9

by Amos Feng (JIRA)

Amos Feng created WFLY-9158: ------------------------------- Summary: Provider com.sun.deploy.security.MozillaJSSProvider could not be instantiated when running the secman integration tests with JDK-9 Key: WFLY-9158 URL: https://issues.jboss.org/browse/WFLY-9158 Project: WildFly Issue Type: Bug Components: Security Manager, Test Suite Reporter: Amos Feng Assignee: Stefan Guilhen {noformat} 09:42:17,202 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.providers.elytron: org.jboss.msc.service.StartException in service org.wildfly.security.providers.elytron: Failed to start service at org.jboss.msc//org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.util.ServiceConfigurationError: java.security.Provider: Provider com.sun.deploy.security.MozillaJSSProvider could not be instantiated at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:581) at java.base/java.util.ServiceLoader.access$100(ServiceLoader.java:390) at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:799) at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:721) at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1389) at java.base/java.lang.Iterable.forEach(Iterable.java:74) at org.wildfly.extension.elytron//org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:203) at org.wildfly.extension.elytron//org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:160) at org.wildfly.extension.elytron//org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) at org.jboss.msc//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) at org.jboss.msc//org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) ... 3 more Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.security.SecurityPermission" "putProviderProperty.SunDeploy-MozillaJSS")" in code source "null" of "null") at org.wildfly.security.elytron-private//org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) at org.wildfly.security.elytron-private//org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) at java.base/java.lang.SecurityManager.checkSecurityAccess(SecurityManager.java:1792) at org.wildfly.security.elytron-private//org.wildfly.security.manager.WildFlySecurityManager.checkSecurityAccess(WildFlySecurityManager.java:571) at java.base/java.security.Provider.check(Provider.java:848) at java.base/java.security.Provider.putService(Provider.java:1337) at jdk.deploy@9/com.sun.deploy.security.MozillaJSSProvider.access$000(MozillaJSSProvider.java:33) at jdk.deploy@9/com.sun.deploy.security.MozillaJSSProvider$1.run(MozillaJSSProvider.java:97) at jdk.deploy@9/com.sun.deploy.security.MozillaJSSProvider$1.run(MozillaJSSProvider.java:90) at java.base/java.security.AccessController.doPrivileged(Native Method) at jdk.deploy(a)9/com.sun.deploy.security.MozillaJSSProvider.<init>(MozillaJSSProvider.java:90) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:488) at java.base/java.util.ServiceLoader$ProviderImpl$2.run(ServiceLoader.java:785) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:790) ... 11 more {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-109) Update syslog handler attributes

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-109?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-109: --------------------------------- Fix Version/s: 4.0.0.Alpha1 > Update syslog handler attributes > -------------------------------- > > Key: WFCORE-109 > URL: https://issues.jboss.org/browse/WFCORE-109 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > Fix For: 4.0.0.Alpha1 > > > The syslog handler does not currently expose the formatter for formatting messages. There will also be changes in a future logmanager release for TCP support and various other properties based on the new TCP support. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2017