[JBoss JIRA] (WFLY-11448) NullPointerException when check operation is called on a server started in admin mode
by Claudio Miranda (Jira)
Claudio Miranda created WFLY-11448:
--------------------------------------
Summary: NullPointerException when check operation is called on a server started in admin mode
Key: WFLY-11448
URL: https://issues.jboss.org/browse/WFLY-11448
Project: WildFly
Issue Type: Bug
Components: MP Health
Reporter: Claudio Miranda
Assignee: Jeff Mesnil
Start standalone with --admin-only
HAL calls the "check" operation when the user navigates to the runtime view, then there is this exception.
{code}
/subsystem=microprofile-health-smallrye:check
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
"rolled-back" => true
}
{code}
{code}
WFLYCTL0013: Operation ("check") failed - address: ([("subsystem" => "microprofile-health-smallrye")]): java.lang.NullPointerException
at org.wildfly.extension.microprofile.health.CheckOperation.executeRuntimeStep(CheckOperation.java:59)
at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:59)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:289)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:255)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:240)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:138)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:162)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:158)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:313)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:158)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (WFLY-11340) Tests in org.jboss.as.test.integration.microprofile.opentracing failing with security manager
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11340?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFLY-11340:
--------------------------------------
I've filed an issue for [JAX-RS|https://github.com/eclipse-ee4j/jaxrs-api/issues/708] and a PR with [FasterXML|https://github.com/FasterXML/jackson-jaxrs-providers/pull/109].
> Tests in org.jboss.as.test.integration.microprofile.opentracing failing with security manager
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-11340
> URL: https://issues.jboss.org/browse/WFLY-11340
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing, Test Suite
> Affects Versions: 14.0.0.Final
> Reporter: Martin Choma
> Assignee: Jan Stourac
> Priority: Major
> Labels: security-manager
>
> These tests fail with security manager from package org.jboss.as.test.integration.microprofile.opentracing
> * ResourceNotTracedTestCase.notTracedEndpointYieldsNoSpans
> * ResourceTracedTestCase.tracedEndpointYieldsSpan
> * ResourceWithCDITestCase.tracedEndpointYieldsSpan
> * ResourceWithCustomOperationNameBeanTestCase.customOperationName
> * SimpleRestClientTestCase.clientRequestSpanJoinsServer
> {noformat}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "modifyThread")" in code source "(vfs:/content/3f3aff01-8e62-42e9-81c0-022f693ec7e0.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.3f3aff01-8e62-42e9-81c0-022f693ec7e0.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:742)
> at java.util.concurrent.ThreadPoolExecutor.shutdownNow(ThreadPoolExecutor.java:1429)
> at java.util.concurrent.Executors$DelegatedExecutorService.shutdownNow(Executors.java:670)
> at org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:63)
> at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:82)
> at org.jboss.as.test.integration.microprofile.opentracing.ResourceNotTracedTestCase.performCall(ResourceNotTracedTestCase.java:63)
> at org.jboss.as.test.integration.microprofile.opentracing.ResourceNotTracedTestCase.notTracedEndpointYieldsNoSpans(ResourceNotTracedTestCase.java:57)
> {noformat}
> As stacktrace is from test side and tests are missing @RunAsClient, I believe tests are running in container. [~juraci.costa] is this really intent tests are missing @RunAsClient annotation?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (DROOLS-3387) Update interaction behavior to align with DMN/Stunner.
by Liz Clayton (Jira)
Liz Clayton created DROOLS-3387:
-----------------------------------
Summary: Update interaction behavior to align with DMN/Stunner.
Key: DROOLS-3387
URL: https://issues.jboss.org/browse/DROOLS-3387
Project: Drools
Issue Type: Task
Components: Scenario Simulation and Testing
Reporter: Liz Clayton
Assignee: Daniele Zonca
Align grid interactions to be consistent with DMN updates:
- Single-click to select a cell
- double-click to edit a cell inline.
- single click to launch a pop-over menu.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (WFCORE-4242) allow empty values for Elytron security identity attributes
by Diana Vilkolakova (Jira)
Diana Vilkolakova created WFCORE-4242:
-----------------------------------------
Summary: allow empty values for Elytron security identity attributes
Key: WFCORE-4242
URL: https://issues.jboss.org/browse/WFCORE-4242
Project: WildFly Core
Issue Type: Enhancement
Components: Security
Reporter: Diana Vilkolakova
Assignee: Diana Vilkolakova
Security identity in Elytron can have attributes associated with it. Right now, when adding attribute through CLI, values must have a minimum length of 1 character. However, it makes sense to allow empty value for an attribute (e.g., for the case where some information is optional so we may not have all the values)
Eg, right now, when adding attribute with empty string for a value through CLI:
{quote}/subsystem=elytron/filesystem-realm=exampleRealm:add-identity-attribute(identity=example, name=Address, value=[""]){quote}
will result in the following error:
{quote}"WFLYCTL0113: '' is an invalid value for parameter value. Values must have a minimum length of 1 characters"{quote}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (JGRP-2315) ASYNC_ENCRYPT: Race condition in cipher queue usage can cause message decryption failures
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2315?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2315:
---------------------------
Fix Version/s: 4.0.16
> ASYNC_ENCRYPT: Race condition in cipher queue usage can cause message decryption failures
> -----------------------------------------------------------------------------------------
>
> Key: JGRP-2315
> URL: https://issues.jboss.org/browse/JGRP-2315
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
> Fix For: 4.0.16
>
>
> If a message is received that needs to be decrypted, or if a message need to be encrypted, a cipher is taken from the queue. However, if a new coordinator concurrently sends a new secret key, it will clear and recreate the cipher queues. If the previous operation then puts its cipher back on the queue, the queue will now contain a cipher with the old secret key. This will result in random message decryption failures when a message encryption/decryption pulls the outdated cipher from the queue.
> While this is mitigated somewhat by the caching of old cipher versions, newly joined members do not have the ability to read messages encrypted by outdated ciphers.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (JGRP-2279) Error during ASYM_ENCRYPT-----exception occurred decrypting message javax.crypto.BadPaddingException: Given final block not properly padded
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2279?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2279:
---------------------------
Fix Version/s: 4.0.16
(was: 4.0.13)
> Error during ASYM_ENCRYPT-----exception occurred decrypting message javax.crypto.BadPaddingException: Given final block not properly padded
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2279
> URL: https://issues.jboss.org/browse/JGRP-2279
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Environment: OS:Red Hat
> JDK:1.8
> Reporter: George Jiang
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 4.0.16
>
> Attachments: asym-ssl2.xml, jgroups-protocol.xml
>
>
> *asym parameters:*
> <ASYM_ENCRYPT encrypt_entire_message="true"
> sign_msgs="true"
> sym_keylength="128"
> sym_algorithm="AES/ECB/PKCS5Padding"
> asym_keylength="2048"
> asym_algorithm="RSA"
> change_key_on_leave="true"/>
> *Throws the following error:*
> 2018-05-23T03:11:53,891 +2903450778 [jgroups--12467,-1491537117,1] ERROR org.jgroups.protocols.ASYM_ENCRYPT - 1: failed decrypting message from 2 (offset=0, length=1136, buf.length=1136): javax.crypto.BadPaddingException: Given final block not properly padded, headers are ASYM_ENCRYPT: [ENCRYPT version=16 bytes], TP: [cluster_name=-1491537117]
> 2018-05-23T03:11:53,893 +2903450780 [jgroups--12467,-1491537117,1] TRACE org.jgroups.protocols.TCP_NIO2 - 1: received message batch of 1 messages from 2
> 2018-05-23T03:11:53,895 +2903450782 [jgroups--12467,-1491537117,1] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 1: received secret key from keyserver 2
> 2018-05-23T03:11:53,895 +2903450782 [jgroups--12467,-1491537117,1] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 1: created 8 symmetric ciphers with secret key (16 bytes)
> 2018-05-23T03:11:54,369 +2903451256 [jgroups--12467,-1491537117,1] TRACE org.jgroups.protocols.TCP_NIO2 - 1: received [dst:***
> 2018-05-23T03:11:54,369 +2903451256 [jgroups--12467,-1491537117,1] WARN org.jgroups.protocols.ASYM_ENCRYPT - 1: exception occurred decrypting message
> javax.crypto.BadPaddingException: Given final block not properly padded
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:991) ~[sunjce_provider.jar:1.8.0_162]
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:847) ~[sunjce_provider.jar:1.8.0_162]
> at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) ~[sunjce_provider.jar:1.8.0_162]
> at javax.crypto.Cipher.doFinal(Cipher.java:2222) ~[?:1.8.0_171]
> at org.jgroups.protocols.Encrypt.code(Encrypt.java:365) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.decryptChecksum(Encrypt.java:387) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt._decrypt(Encrypt.java:299) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.decryptMessage(Encrypt.java:283) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.handleEncryptedMessage(Encrypt.java:242) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.handleUpMessage(Encrypt.java:229) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.up(Encrypt.java:155) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.ASYM_ENCRYPT.up(ASYM_ENCRYPT.java:143) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:129) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:197) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:252) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:277) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Discovery.up(Discovery.java:262) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1203) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_162]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_162]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_162]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (JGRP-2315) ASYNC_ENCRYPT: Race condition in cipher queue usage can cause message decryption failures
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/JGRP-2315?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated JGRP-2315:
-------------------------------
Description:
If a message is received that needs to be decrypted, or if a message need to be encrypted, a cipher is taken from the queue. However, if a new coordinator concurrently sends a new secret key, it will clear and recreate the cipher queues. If the previous operation then puts its cipher back on the queue, the queue will now contain a cipher with the old secret key. This will result in random message decryption failures when a message encryption/decryption pulls the outdated cipher from the queue.
While this is mitigated somewhat by the caching of old cipher versions, newly joined members do not have the ability to read messages encrypted by outdated ciphers.
was:If a message is received that needs to be decrypted, or if a message need to be encrypted, a cipher is taken from the queue. However, if a new coordinator concurrently sends a new secret key, it will clear and recreate the cipher queues. If the previous operation then puts its cipher back on the queue, the queue will now contain a cipher with the old secret key. This will result in random message decryption failures when a message encryption/decryption pulls the outdated cipher from the queue.
> ASYNC_ENCRYPT: Race condition in cipher queue usage can cause message decryption failures
> -----------------------------------------------------------------------------------------
>
> Key: JGRP-2315
> URL: https://issues.jboss.org/browse/JGRP-2315
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Major
>
> If a message is received that needs to be decrypted, or if a message need to be encrypted, a cipher is taken from the queue. However, if a new coordinator concurrently sends a new secret key, it will clear and recreate the cipher queues. If the previous operation then puts its cipher back on the queue, the queue will now contain a cipher with the old secret key. This will result in random message decryption failures when a message encryption/decryption pulls the outdated cipher from the queue.
> While this is mitigated somewhat by the caching of old cipher versions, newly joined members do not have the ability to read messages encrypted by outdated ciphers.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years