[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, 7 months
[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, 7 months
[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, 7 months
[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, 7 months
[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, 7 months
[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 reassigned JGRP-2315:
----------------------------------
Assignee: Paul Ferraro (was: Bela Ban)
> 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
>
> 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, 7 months
[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:
-------------------------------
Summary: ASYNC_ENCRYPT: Race condition in cipher queue usage can cause message decryption failures (was: ASYNC_ENCRYPT: Race condition in cipher queue usage can cause message descryption failures)
> 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.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3358) Add possibility to choose between rule and DMN in scenario creation popup
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3358?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi updated DROOLS-3358:
-------------------------------------
Description: Modify the "new Scenario" creation popup to allow choosing between DRL/DMN. In case of DMN, allow the user to select an already uploaded DMN file (was: As user I want to create a simulation to test rules or DMN model)
> Add possibility to choose between rule and DMN in scenario creation popup
> -------------------------------------------------------------------------
>
> Key: DROOLS-3358
> URL: https://issues.jboss.org/browse/DROOLS-3358
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: ScenarioSimulation
>
> Modify the "new Scenario" creation popup to allow choosing between DRL/DMN. In case of DMN, allow the user to select an already uploaded DMN file
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (JGRP-2315) ASYNC_ENCRYPT: Race condition in cipher queue usage can cause message descryption failures
by Paul Ferraro (Jira)
Paul Ferraro created JGRP-2315:
----------------------------------
Summary: ASYNC_ENCRYPT: Race condition in cipher queue usage can cause message descryption 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
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.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (JBJCA-1380) XAManagedConnectionFactory screws up Datasource urls containing ;
by Yannick Einsweiler (Jira)
[ https://issues.jboss.org/browse/JBJCA-1380?page=com.atlassian.jira.plugin... ]
Yannick Einsweiler edited comment on JBJCA-1380 at 11/29/18 10:36 AM:
----------------------------------------------------------------------
[~chrispoulsen] same here.
Not sure why semicolon was replaced in the first place but you cannot just comment out that line as the User and Password properties are concatenated to it using semicolon.
As such you must only replace for those properties which have a setter in _org.h2.jdbcx.JdbcDataSource_, that is, User, Password and URL. Replace the offending line with:
{code:java}
xaDataSourceProperties = xaDataSourceProperties.replaceAll("(?i);(user|password|url)", "\n$1");
{code}
was (Author: einsweiy):
[~chrispoulsen] same here.
Not sure why semicolon was replaced in the first place but you cannot just comment out that line as the User and Password properties are concatenated to it using semicolon.
As such you must only replace for those properties which have a setter in _org.h2.jdbcx.JdbcDataSource_, that is, User, Password and URL. Replace the offending line with:
{code:java}
xaDataSourceProperties = xaDataSourceProperties.replaceAll('(?i);(user|password|url)', '\n$1');
{code}
> XAManagedConnectionFactory screws up Datasource urls containing ;
> -----------------------------------------------------------------
>
> Key: JBJCA-1380
> URL: https://issues.jboss.org/browse/JBJCA-1380
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.4.9
> Environment: Unit testing using an embedded ironjacamar
> Reporter: Chris Poulsen
> Priority: Major
> Attachments: XAManagedConnectionFactory-h2-error.txt
>
>
> While trying to adjust settings on the H2 data source we use for a corner of our system during testing, I ran into problems.
> H2 accepts parameters appended to the url on the form ";<name>=<value>" for example:
> "jdbc:h2:mem:unit-test;MODE=Oracle"
> I was unable to deploy the datasource using:
> <xa-datasource-property name="url">jdbc:h2:mem:unit-test;MODE=Oracle</xa-datasource-property>
> Ironjacamar keeps complaining about:
> Caused by: java.lang.NoSuchMethodException: Method setMODE not found some setter not being found.
> My initial thought was that <url-delimiter> was the cause, but no dice.
> Following the trace into the sources, I guess the offending line is:
> {code:java}
> xaDataSourceProperties = xaDataSourceProperties.replace(';', '\n');
> {code}
> In XAManagedConnectionFactory around line: 174 (see following snippet)
> {code:java}
> public void setXADataSourceProperties(String xaDataSourceProperties) throws ResourceException
> {
> this.xaDataSourceProperties = xaDataSourceProperties;
> xaProps.clear();
> if (xaDataSourceProperties != null)
> {
> // Map any \ to \\
> xaDataSourceProperties = xaDataSourceProperties.replaceAll("\\\\", "\\\\\\\\");
> // Map any ; to \n
> xaDataSourceProperties = xaDataSourceProperties.replace(';', '\n');
> InputStream is = new ByteArrayInputStream(xaDataSourceProperties.getBytes());
> try
> {
> Properties p = new Properties();
> p.load(is);
> for (Map.Entry<Object, Object> entry : p.entrySet())
> {
> xaProps.put((String)entry.getKey(), (String)entry.getValue());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months