[Red Hat JIRA] (WFLY-14428) [Wildfly Artemis] Message mix if traffic load high
by terry liang (Jira)
terry liang created WFLY-14428:
----------------------------------
Summary: [Wildfly Artemis] Message mix if traffic load high
Key: WFLY-14428
URL: https://issues.redhat.com/browse/WFLY-14428
Project: WildFly
Issue Type: Bug
Affects Versions: 16.0.0.Final
Reporter: terry liang
Assignee: Brian Stansberry
The Artemis would mix up message if traffic load is high, such as JMSCorrelationId is the same, but the body change between sending and receiving request.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (JGRP-2528) Hardcoded password detected
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2528?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2528:
--------------------------------
This is not an issue as the password can be injected by means of a system property, or programmatically. The "changeit" value is just a sample. Nothing there to see, move on... :-)
> Hardcoded password detected
> ---------------------------
>
> Key: JGRP-2528
> URL: https://issues.redhat.com/browse/JGRP-2528
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Mahir Kabir
> Assignee: Bela Ban
> Priority: Major
>
> We are a security research team at Virginia Tech. We are doing an empirical study about the usefulness of the existing security vulnerability detection tools. The following is a reported vulnerability by certain tools. We'll appreciate it if you can give any feedback on it.
> *Vulnerability Location:*
> in file https://github.com/belaban/JGroups/blob/32359fa52dc96bacc78792afdaa51cc1a..., line 107 invokes store.load() with store_password, which is assigned with a constant value "changeit".
> *Security Impact:*
> Keystore password should not be kept in the source code. The source code can be widely shared in an enterprise environment and is certainly shared in open source. The product transmits or stores authentication credentials, but it uses an insecure way that is susceptible to unauthorized interception and/or retrieval.
> *suggestions:*
> To be managed safely, passwords or secret keys should be stored in separate configuration files or keystores. The Keystore password is better to load from the locally set files instead of directly set in the code.
> Useful link:
> [https://cwe.mitre.org/data/definitions/321.html]
> [https://cwe.mitre.org/data/definitions/522.html]
> [https://www.baeldung.com/java-keystore]
> *Please share with us your opinions/comments if there is any:*
> Is the bug report helpful?
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-6016) Drools throws illegal reflective access errors.
by Mirtunjay Singh (Jira)
Mirtunjay Singh created DROOLS-6016:
---------------------------------------
Summary: Drools throws illegal reflective access errors.
Key: DROOLS-6016
URL: https://issues.redhat.com/browse/DROOLS-6016
Project: Drools
Issue Type: Enhancement
Reporter: Mirtunjay Singh
Assignee: Mario Fusco
Drools throws illegal reflective access errors when --illegal-access=deny flag is set.
[JEP 396|https://openjdk.java.net/jeps/396] will strongly encapsulate JDK internals by default. This means that {{--illegal-access-}} parameter will no longer default to {{permit}} in Java 16 or 17. It will default to {{deny}}.
*Error when the illegal-access flag is set as deny.*
_java.lang.ExceptionInInitializerError: null_
_at com.thoughtworks.xstream.XStream.setupConverters(XStream.java:989)_
_at com.thoughtworks.xstream.XStream.<init>(XStream.java:592)_
_at com.thoughtworks.xstream.XStream.<init>(XStream.java:514)_
_at com.thoughtworks.xstream.XStream.<init>(XStream.java:483)_
_at com.thoughtworks.xstream.XStream.<init>(XStream.java:429)_
_at com.thoughtworks.xstream.XStream.<init>(XStream.java:396)_
_at org.kie.soup.commons.xstream.XStreamUtils.createTrustingXStream(XStreamUtils.java:119)_
_at org.drools.compiler.kproject.models.KieModuleModelImpl$kModuleMarshaller.<init>(KieModuleModelImpl.java:170)_
_at org.drools.compiler.kproject.models.KieModuleModelImpl$kModuleMarshaller.<init>(KieModuleModelImpl.java:169)_
_at org.drools.compiler.kproject.models.KieModuleModelImpl.<clinit>(KieModuleModelImpl.java:167)_
_at org.drools.compiler.kie.builder.impl.ClasspathKieProject.fetchKModule(ClasspathKieProject.java:180)_
_at org.drools.compiler.kie.builder.impl.ClasspathKieProject.fetchKModule(ClasspathKieProject.java:142)_
_at org.drools.compiler.kie.builder.impl.ClasspathKieProject.discoverKieModules(ClasspathKieProject.java:113)_
_at org.drools.compiler.kie.builder.impl.ClasspathKieProject.init(ClasspathKieProject.java:85)_
_at org.drools.compiler.kie.builder.impl.KieContainerImpl.<init>(KieContainerImpl.java:138)_
_at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieClasspathContainer(KieServicesImpl.java:135)_
_at org.drools.compiler.kie.builder.impl.KieServicesImpl.getKieClasspathContainer(KieServicesImpl.java:101)_
_at org.drools.compiler.kie.builder.impl.KieServicesImpl.getKieClasspathContainer(KieServicesImpl.java:79)_
_at com.somepackage.SomeClass.someMethod(SomeClass.java:35)_
_Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field private final java.util.Comparator java.util.TreeMap.comparator accessible: module java.base does not "opens java.util" to unnamed module @28486680_
_at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)_
_at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)_
_at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:176)_
_at java.base/java.lang.reflect.Field.setAccessible(Field.java:170)_
_at com.thoughtworks.xstream.core.util.Fields.locate(Fields.java:40)_
_at com.thoughtworks.xstream.converters.collections.TreeMapConverter.<clinit>(TreeMapConverter.java:50)_
_... 24 common frames omitted_
*Warnings when the illegal-access flag is set to debug.*
_WARNING: Illegal reflective access by com.thoughtworks.xstream.core.util.Fields (file:/libs/xstream-1.4.10.jar) to field java.util.TreeSet.m_
_at com.thoughtworks.xstream.core.util.Fields.locate(Fields.java:40)_
_at com.thoughtworks.xstream.converters.collections.TreeSetConverter.<clinit>(TreeSetConverter.java:48)_
_at com.thoughtworks.xstream.XStream.setupConverters(XStream.java:990)_
_at com.thoughtworks.xstream.XStream.<init>(XStream.java:592)_
_at com.thoughtworks.xstream.XStream.<init>(XStream.java:514)_
_at com.thoughtworks.xstream.XStream.<init>(XStream.java:483)_
_at com.thoughtworks.xstream.XStream.<init>(XStream.java:429)_
_at com.thoughtworks.xstream.XStream.<init>(XStream.java:396)_
_at org.kie.soup.commons.xstream.XStreamUtils.createTrustingXStream(XStreamUtils.java:119)_
_at org.drools.compiler.kproject.models.KieModuleModelImpl$kModuleMarshaller.<init>(KieModuleModelImpl.java:170)_
_at org.drools.compiler.kproject.models.KieModuleModelImpl$kModuleMarshaller.<init>(KieModuleModelImpl.java:169)_
_at org.drools.compiler.kproject.models.KieModuleModelImpl.<clinit>(KieModuleModelImpl.java:167)_
_at org.drools.compiler.kie.builder.impl.ClasspathKieProject.fetchKModule(ClasspathKieProject.java:180)_
_at org.drools.compiler.kie.builder.impl.ClasspathKieProject.fetchKModule(ClasspathKieProject.java:142)_
_at org.drools.compiler.kie.builder.impl.ClasspathKieProject.discoverKieModules(ClasspathKieProject.java:113)_
_at org.drools.compiler.kie.builder.impl.ClasspathKieProject.init(ClasspathKieProject.java:85)_
_at org.drools.compiler.kie.builder.impl.KieContainerImpl.<init>(KieContainerImpl.java:138)_
_at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieClasspathContainer(KieServicesImpl.java:135)_
_at org.drools.compiler.kie.builder.impl.KieServicesImpl.getKieClasspathContainer(KieServicesImpl.java:101)_
_at org.drools.compiler.kie.builder.impl.KieServicesImpl.getKieClasspathContainer(KieServicesImpl.java:79)_
_at com.somepackage.SomeClass.someMethod(SomeClass.java:35)_
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (JGRP-2528) Hardcoded password detected
by Mahir Kabir (Jira)
Mahir Kabir created JGRP-2528:
---------------------------------
Summary: Hardcoded password detected
Key: JGRP-2528
URL: https://issues.redhat.com/browse/JGRP-2528
Project: JGroups
Issue Type: Enhancement
Reporter: Mahir Kabir
Assignee: Bela Ban
We are a security research team at Virginia Tech. We are doing an empirical study about the usefulness of the existing security vulnerability detection tools. The following is a reported vulnerability by certain tools. We'll appreciate it if you can give any feedback on it.
*Vulnerability Location:*
in file https://github.com/belaban/JGroups/blob/32359fa52dc96bacc78792afdaa51cc1a..., line 107 invokes store.load() with store_password, which is assigned with a constant value "changeit".
*Security Impact:*
Keystore password should not be kept in the source code. The source code can be widely shared in an enterprise environment and is certainly shared in open source. The product transmits or stores authentication credentials, but it uses an insecure way that is susceptible to unauthorized interception and/or retrieval.
*suggestions:*
To be managed safely, passwords or secret keys should be stored in separate configuration files or keystores. The Keystore password is better to load from the locally set files instead of directly set in the code.
Useful link:
[https://cwe.mitre.org/data/definitions/321.html]
[https://cwe.mitre.org/data/definitions/522.html]
[https://www.baeldung.com/java-keystore]
*Please share with us your opinions/comments if there is any:*
Is the bug report helpful?
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14421) Too many open file Descriptors in Wildfly-18
by Manas Panda (Jira)
[ https://issues.redhat.com/browse/WFLY-14421?page=com.atlassian.jira.plugi... ]
Manas Panda edited comment on WFLY-14421 at 2/11/21 11:50 PM:
--------------------------------------------------------------
we are checking with file Descriptors under JVM process.
was (Author: JIRAUSER152967):
we are checking with file Descriptors under the JVM process.
> Too many open file Descriptors in Wildfly-18
> --------------------------------------------
>
> Key: WFLY-14421
> URL: https://issues.redhat.com/browse/WFLY-14421
> Project: WildFly
> Issue Type: Task
> Reporter: Manas Panda
> Assignee: Brian Stansberry
> Priority: Major
>
> In the application code deployed in wildfly10, if the fileinputstream is not closed programmatically (its a miss in the code), during the GC (G1GC) cycle, the orphan references of the opened file input streams are closed, so the number of open file descriptor is not growing.
> However, after the upgrade of the wildfly10 to wildfly18, the file input streams which are not closed programmatically are not getting closed during the GC (G1GC) cycle due to which the number of open file descriptors are growing.
> We agree that the input streams have to be closed programmatically in the application code which we did now, but would like to understand the reason behind this behavior change in wildfly18.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14421) Too many open file Descriptors in Wildfly-18
by Manas Panda (Jira)
[ https://issues.redhat.com/browse/WFLY-14421?page=com.atlassian.jira.plugi... ]
Manas Panda edited comment on WFLY-14421 at 2/11/21 11:50 PM:
--------------------------------------------------------------
we are checking with file Descriptors under the JVM process.
was (Author: JIRAUSER152967):
re checking with file Descriptors under the JVM process.
> Too many open file Descriptors in Wildfly-18
> --------------------------------------------
>
> Key: WFLY-14421
> URL: https://issues.redhat.com/browse/WFLY-14421
> Project: WildFly
> Issue Type: Task
> Reporter: Manas Panda
> Assignee: Brian Stansberry
> Priority: Major
>
> In the application code deployed in wildfly10, if the fileinputstream is not closed programmatically (its a miss in the code), during the GC (G1GC) cycle, the orphan references of the opened file input streams are closed, so the number of open file descriptor is not growing.
> However, after the upgrade of the wildfly10 to wildfly18, the file input streams which are not closed programmatically are not getting closed during the GC (G1GC) cycle due to which the number of open file descriptors are growing.
> We agree that the input streams have to be closed programmatically in the application code which we did now, but would like to understand the reason behind this behavior change in wildfly18.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14421) Too many open file Descriptors in Wildfly-18
by Manas Panda (Jira)
[ https://issues.redhat.com/browse/WFLY-14421?page=com.atlassian.jira.plugi... ]
Manas Panda commented on WFLY-14421:
------------------------------------
re checking with file Descriptors under the JVM process.
> Too many open file Descriptors in Wildfly-18
> --------------------------------------------
>
> Key: WFLY-14421
> URL: https://issues.redhat.com/browse/WFLY-14421
> Project: WildFly
> Issue Type: Task
> Reporter: Manas Panda
> Assignee: Brian Stansberry
> Priority: Major
>
> In the application code deployed in wildfly10, if the fileinputstream is not closed programmatically (its a miss in the code), during the GC (G1GC) cycle, the orphan references of the opened file input streams are closed, so the number of open file descriptor is not growing.
> However, after the upgrade of the wildfly10 to wildfly18, the file input streams which are not closed programmatically are not getting closed during the GC (G1GC) cycle due to which the number of open file descriptors are growing.
> We agree that the input streams have to be closed programmatically in the application code which we did now, but would like to understand the reason behind this behavior change in wildfly18.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14427) Fix usages of the credential-reference schema in the Undertow subsystem
by Farah Juma (Jira)
Farah Juma created WFLY-14427:
---------------------------------
Summary: Fix usages of the credential-reference schema in the Undertow subsystem
Key: WFLY-14427
URL: https://issues.redhat.com/browse/WFLY-14427
Project: WildFly
Issue Type: Task
Components: Security, Web (Undertow)
Reporter: Farah Juma
Assignee: Farah Juma
There are some issues with the current usages of the credential-reference schema in the Undertow subsystem:
* WFLY-12217 originally updated various subsystem schemas to reference the new XML schema for {{credential-reference}} ({{urn:wildfly:credential-reference:1.0}}). As part of this change, wildfly-undertow_9_0.xsd was updated to make use of this schema, as shown here (notice that the {{credential-reference}} schema was imported and the rest of the file was updated to make use of the {{credentialReferenceType}} provided by the schema):
[https://github.com/wildfly/wildfly/pull/12378/files#diff-c5cdb3e1bfa441b2...]
* WFLY-12173 then added *wildfly-undertow_10_0.xsd* but accidentally left out the {{credential-reference}} changes (it looks like the PR for this was merged very shortly after WFLY-12217 which explains why the new schema file might not have been copied from the right version of *wildfly-undertow_9_0.xsd*).
* WFLY-13369 then added *wildfly-undertow_11_0.xsd* by copying from the incorrect *wildfly-undertow_10_0.xsd* but corrected the latter file to use the {{urn:wildfly:credential-reference:1.0}} schema again. However, the additional changes from *wildfly-undertow_9_0.xsd* that update the file to actually make use of the {{credentialReferenceType}} provided from the schema were accidentally left out.
As discussed with Flavia, the following two changes should be made to clean things up:
* Remove the credential-reference schema import from {{wildfly-undertow_10_0.xsd}} since it is unused.
* Make use of the imported credential-reference schema in {{wildfly-undertow_11_0.xsd}} and remove the redundant types
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months