[JBoss JIRA] (WFLY-13320) Wildfly-openssl can not load library wfssl on RHEL6
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13320?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFLY-13320:
------------------------------------
Component/s: Security
(was: Web (Undertow))
> Wildfly-openssl can not load library wfssl on RHEL6
> ---------------------------------------------------
>
> Key: WFLY-13320
> URL: https://issues.redhat.com/browse/WFLY-13320
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Tomas Terem
> Assignee: Flavia Rainone
> Priority: Critical
> Labels: regression
>
> Using OpenSSL on RHEL6 cuases UnsatisfiedLinkError when loading the wfssl library.
> {code:java}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
> at java.security.Provider$Service.newInstance(Provider.java:1617)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
> at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105)
> ... 8 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.wildfly.openssl.SSL.init(SSL.java:87)
> at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129)
> at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:463)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.security.Provider$Service.newInstance(Provider.java:1595)
> ... 12 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.wildfly.openssl.SSL.init(SSL.java:82)
> ... 19 more
> Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1871)
> at java.lang.Runtime.loadLibrary0(Runtime.java:871)
> at java.lang.System.loadLibrary(System.java:1124)
> at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288)
> ... 24 more
> {code}
> The issue was fixed by https://github.com/wildfly-security/wildfly-openssl/commit/dfaa7596a040fb... since version 1.0.9.SP03 of wildfly-openssl.
> However Wildfly 19.0.0.Final uses WildFly Core 11.0.0.Final which uses wildfly-openssl 1.0.9.Final without a fix. (current Wildfly Core master uses wildfly-openssl 1.0.10.Final where the fix is present)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13320) Wildfly-openssl can not load library wfssl on RHEL6
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13320?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFLY-13320:
---------------------------------------
Assignee: Farah Juma (was: Flavia Rainone)
> Wildfly-openssl can not load library wfssl on RHEL6
> ---------------------------------------------------
>
> Key: WFLY-13320
> URL: https://issues.redhat.com/browse/WFLY-13320
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Tomas Terem
> Assignee: Farah Juma
> Priority: Critical
> Labels: regression
>
> Using OpenSSL on RHEL6 cuases UnsatisfiedLinkError when loading the wfssl library.
> {code:java}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
> at java.security.Provider$Service.newInstance(Provider.java:1617)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
> at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105)
> ... 8 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.wildfly.openssl.SSL.init(SSL.java:87)
> at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129)
> at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:463)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.security.Provider$Service.newInstance(Provider.java:1595)
> ... 12 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.wildfly.openssl.SSL.init(SSL.java:82)
> ... 19 more
> Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1871)
> at java.lang.Runtime.loadLibrary0(Runtime.java:871)
> at java.lang.System.loadLibrary(System.java:1124)
> at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288)
> ... 24 more
> {code}
> The issue was fixed by https://github.com/wildfly-security/wildfly-openssl/commit/dfaa7596a040fb... since version 1.0.9.SP03 of wildfly-openssl.
> However Wildfly 19.0.0.Final uses WildFly Core 11.0.0.Final which uses wildfly-openssl 1.0.9.Final without a fix. (current Wildfly Core master uses wildfly-openssl 1.0.10.Final where the fix is present)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-5180) Kie-scanner update container API doesn't refresh container with latest jar after new year
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5180?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-5180.
---------------------------------
Resolution: Cannot Reproduce
I tried to reproduce this issue in all possible ways (playing with the system clock) but couldn't.
> Kie-scanner update container API doesn't refresh container with latest jar after new year
> -----------------------------------------------------------------------------------------
>
> Key: DROOLS-5180
> URL: https://issues.redhat.com/browse/DROOLS-5180
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.18.0.Final
> Reporter: Minal Bhalodi
> Assignee: Mario Fusco
> Priority: Critical
>
> We are using kie-server as a stand alone application. we use kie scanner to update kie container when there is a new DRL file in our .m2 folder.
> we don't have scanner polling but we use Scanner update container API to update kie container.
> Every year when date changes after new year, we are facing issue where kie scanner is not able to update container with latest jar in m2 with new year date.
> When we check the container version it shows latest with new year date but internally kie is still using old jar.
> We fixed this issue with create container API instead update container.
> kie-server-spring-boot-starter-drools :7.18.0.Final
> Please let me know if this issue is already fixed or discussed before or if you need more details.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13322) Ability to configure JSF Implementation instead of modifying the system module
by Brad Maxwell (Jira)
Brad Maxwell created WFLY-13322:
-----------------------------------
Summary: Ability to configure JSF Implementation instead of modifying the system module
Key: WFLY-13322
URL: https://issues.redhat.com/browse/WFLY-13322
Project: WildFly
Issue Type: Enhancement
Components: JSF
Reporter: Brad Maxwell
Assignee: Farah Juma
Modifying modules under modules/system/ should not be required as this breaks patching and requires users to keep re applying the configuration or copying jars around when a patch is applied.
The user should be able to create a module with a different JSF implementation and depend on org.jboss.as.jsf-injection or such and it work without having to modify the org.jboss.as.jsf-injection module.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13320) Wildfly-openssl can not load library wfssl on RHEL6
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFLY-13320?page=com.atlassian.jira.plugi... ]
Jan Stourac updated WFLY-13320:
-------------------------------
Fix Version/s: (was: 19.0.0.Final)
> Wildfly-openssl can not load library wfssl on RHEL6
> ---------------------------------------------------
>
> Key: WFLY-13320
> URL: https://issues.redhat.com/browse/WFLY-13320
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 19.0.0.Final
> Reporter: Tomas Terem
> Assignee: Flavia Rainone
> Priority: Critical
> Labels: regression
>
> Using OpenSSL on RHEL6 cuases UnsatisfiedLinkError when loading the wfssl library.
> {code:java}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
> at java.security.Provider$Service.newInstance(Provider.java:1617)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
> at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105)
> ... 8 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.wildfly.openssl.SSL.init(SSL.java:87)
> at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129)
> at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:463)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.security.Provider$Service.newInstance(Provider.java:1595)
> ... 12 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.wildfly.openssl.SSL.init(SSL.java:82)
> ... 19 more
> Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1871)
> at java.lang.Runtime.loadLibrary0(Runtime.java:871)
> at java.lang.System.loadLibrary(System.java:1124)
> at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288)
> ... 24 more
> {code}
> The issue was fixed by https://github.com/wildfly-security/wildfly-openssl/commit/dfaa7596a040fb... since version 1.0.9.SP03 of wildfly-openssl.
> However Wildfly 19.0.0.Final uses WildFly Core 11.0.0.Final which uses wildfly-openssl 1.0.9.Final without a fix. (current Wildfly Core master uses wildfly-openssl 1.0.10.Final where the fix is present)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13321) Update references to WildFlyElytronProvider in the Elytron documentation
by Farah Juma (Jira)
Farah Juma created WFLY-13321:
---------------------------------
Summary: Update references to WildFlyElytronProvider in the Elytron documentation
Key: WFLY-13321
URL: https://issues.redhat.com/browse/WFLY-13321
Project: WildFly
Issue Type: Task
Components: Documentation, Security
Reporter: Farah Juma
When Elytron was converted to a multi-module project, [WildFlyElytronProvider|https://wildfly-security.github.io/wildfly-elytron/master/org/wildfly/security/WildFlyElytronProvider.html] was deprecated and provider implementations were added for the individual modules (e.g., [WildFlyElytronPasswordProvider|https://wildfly-security.github.io/wildfly-elytron/1.11.x/api-javadoc/org/wildfly/security/password/WildFlyElytronPasswordProvider.html], [WildFlyElytronCredentialStoreProvider|https://wildfly-security.github.io/wildfly-elytron/1.11.x/api-javadoc/org/wildfly/security/credential/store/WildFlyElytronCredentialStoreProvider.html], etc.). However, the [Elytron security guide|https://docs.wildfly.org/19/WildFly_Elytron_Security.html] still references the deprecated {{WildFlyElytronProvider}} class instead of referencing the new provider implementations. This should be updated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13304) JwtActivationProcessor throws NPE when LoginConfig#realmName not declared
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13304?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFLY-13304:
------------------------------------
Workaround Description: Define the auth-method within a web.xml deployment descriptor, the web.xml takes priority over the annotation so the code triggering the NPE will be skipped if already defined in the web.xml.
Workaround: Workaround Exists
> JwtActivationProcessor throws NPE when LoginConfig#realmName not declared
> -------------------------------------------------------------------------
>
> Key: WFLY-13304
> URL: https://issues.redhat.com/browse/WFLY-13304
> Project: WildFly
> Issue Type: Bug
> Components: MP JWT
> Affects Versions: 19.0.0.Final
> Reporter: Michael Edgar
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 19.0.1.Final, 20.0.0.Beta1
>
>
> When starting a Microprofile application utilizing the {{org.eclipse.microprofile.auth.LoginConfig}} annotation, a {{NullPointerException}} is thrown if the annotation does not declare the {{realmName}} property.
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) {} MSC000001: Failed to start service jboss.deployment.unit."example.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."example.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "example.war"
> at org.jboss.as.server@11.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.microprofile.jwt-smallrye@19.0.0.Final//org.wildfly.extension.microprofile.jwt.smallrye.JwtActivationProcessor.deploy(JwtActivationProcessor.java:80)
> at org.jboss.as.server@11.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> ... 8 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months