June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13549) CVE-2020-10740 Unsafe deserialization in Wildfly Naming/EJB

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13549?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13549: ------------------------------------ Security: (was: Security Issue) > CVE-2020-10740 Unsafe deserialization in Wildfly Naming/EJB > ----------------------------------------------------------- > > Key: WFLY-13549 > URL: https://issues.redhat.com/browse/WFLY-13549 > Project: WildFly > Issue Type: Bug > Components: EJB, Naming > Affects Versions: 18.0.0.Final, 18.0.1.Final, 19.0.0.Final, 19.1.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Fix For: 20.0.0.Final > > > A lack of input validation/filtering capabilities for applications running on the application server using it's JNDI or EJB features leave the server vulnerable to deserialization attacks. > See also https://bugzilla.redhat.com/show_bug.cgi?id=1834512 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5397) Data object containing at least one enum fails to be opend in Data model editor

by Anna Dupliak (Jira)

Anna Dupliak created DROOLS-5397: ------------------------------------ Summary: Data object containing at least one enum fails to be opend in Data model editor Key: DROOLS-5397 URL: https://issues.redhat.com/browse/DROOLS-5397 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing Reporter: Anna Dupliak Assignee: Yeser Amer Attachments: EnumFieldOnlyObject.java, EnumTest.java, model view with enum types.webm It is possible to manage enum types in scenario simulation to do so in Rule based test scenario it is possible to have data object enum. But including at least one field that implements Enumeration interface breaks the model editor and fails to show fields on the UI See: [^model view with enum types.webm] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2480) ObjectMessage: better marshalling

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2480?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2480: --------------------------- Description: Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances. This means that primitive types (e.g. "{{7}}" or "{{hello world}}") will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts. Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}. was: Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances. This means that primitive types (e.g. "{{7}}" or "{{hello world}}") will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an (unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts. Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}. > ObjectMessage: better marshalling > --------------------------------- > > Key: JGRP-2480 > URL: https://issues.redhat.com/browse/JGRP-2480 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0.0.Beta2 > > > Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances. > This means that primitive types (e.g. "{{7}}" or "{{hello world}}") will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts. > Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2480) ObjectMessage: better marshalling

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2480?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2480: --------------------------- Description: Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances. This means that primitive types (e.g. "{{7}}" or "{{hello world}}") will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an (unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts. Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}. was: Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances. This means that primitive types (e.g. "{{7}}" or "{{hello world}}" will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an (unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts. Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}. > ObjectMessage: better marshalling > --------------------------------- > > Key: JGRP-2480 > URL: https://issues.redhat.com/browse/JGRP-2480 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0.0.Beta2 > > > Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances. > This means that primitive types (e.g. "{{7}}" or "{{hello world}}") will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an (unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts. > Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2480) ObjectMessage: better marshalling

by Bela Ban (Jira)

Bela Ban created JGRP-2480: ------------------------------ Summary: ObjectMessage: better marshalling Key: JGRP-2480 URL: https://issues.redhat.com/browse/JGRP-2480 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0.0.Beta2 Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances. This means that primitive types (e.g. "{{7}}" or "{{hello world}}" will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an (unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts. Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1977) (7.3.z) Update AcmeClientSpi#obtainCertificate so that it obtains the order URL from the response to newOrder

by Ilia Vassilev (Jira)

Ilia Vassilev created ELY-1977: ---------------------------------- Summary: (7.3.z) Update AcmeClientSpi#obtainCertificate so that it obtains the order URL from the response to newOrder Key: ELY-1977 URL: https://issues.redhat.com/browse/ELY-1977 Project: WildFly Elytron Issue Type: Task Reporter: Ilia Vassilev Assignee: Farah Juma {{AcmeClientSpi#obtainCertificate}} currently determines the order URL that should be used by taking the {{Location}} header from the response to finalizing the order (the ACME protocol specification has an example response that includes this header). This works when obtaining certificates from Let's Encrypt and Boulder. However, it seems that EJBCA does not include the {{Location}} header in the response to finalizing the order. {{AcmeClientSpi#obtainCertificate}} should instead use the Location header from the response to {{newOrder}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13424) External pooled connection factory won't be properly injected if it has several JNDI entries

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13424?page=com.atlassian.jira.plugi... ] Jeff Mesnil commented on WFLY-13424: ------------------------------------ that's what should be done then: if ee got an alias, it should resolve the alias until it got the actual value. I don't think that requiring that the default JMS ConnectionFactory MUST be the first JNDI entries is correct. > External pooled connection factory won't be properly injected if it has several JNDI entries > -------------------------------------------------------------------------------------------- > > Key: WFLY-13424 > URL: https://issues.redhat.com/browse/WFLY-13424 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 19.1.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Major > Fix For: 20.0.0.Beta1 > > > If the default JNDI name for MDB to get the resource adapter is not the first entry of the JNDI names bound for a pooled-connection-factory then the injection fails. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13424) External pooled connection factory won't be properly injected if it has several JNDI entries

by Emmanuel Hugonnet (Jira)

[ https://issues.redhat.com/browse/WFLY-13424?page=com.atlassian.jira.plugi... ] Emmanuel Hugonnet commented on WFLY-13424: ------------------------------------------ because when you are using an alias you don't get the value directly when resolving so you need to resolve again to obtain the proper value. > External pooled connection factory won't be properly injected if it has several JNDI entries > -------------------------------------------------------------------------------------------- > > Key: WFLY-13424 > URL: https://issues.redhat.com/browse/WFLY-13424 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 19.1.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Major > Fix For: 20.0.0.Beta1 > > > If the default JNDI name for MDB to get the resource adapter is not the first entry of the JNDI names bound for a pooled-connection-factory then the injection fails. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13424) External pooled connection factory won't be properly injected if it has several JNDI entries

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13424?page=com.atlassian.jira.plugi... ] Jeff Mesnil commented on WFLY-13424: ------------------------------------ I don't understand why the order of entries is now significant. As long as the JMS ConnectionFactory is properly bound in JNDI, it should be resolved by the `ee` subsystem to provide the default JMS ConnectionFactory (whether it's a direct JNDI entry or an alias) > External pooled connection factory won't be properly injected if it has several JNDI entries > -------------------------------------------------------------------------------------------- > > Key: WFLY-13424 > URL: https://issues.redhat.com/browse/WFLY-13424 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 19.1.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Major > Fix For: 20.0.0.Beta1 > > > If the default JNDI name for MDB to get the resource adapter is not the first entry of the JNDI names bound for a pooled-connection-factory then the injection fails. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13514) Huge memory leak in WildFly

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/WFLY-13514?page=com.atlassian.jira.plugi... ] Flavia Rainone commented on WFLY-13514: --------------------------------------- This issue should be fixed by WFCORE-4988. > Huge memory leak in WildFly > --------------------------- > > Key: WFLY-13514 > URL: https://issues.redhat.com/browse/WFLY-13514 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF, Web (Undertow) > Affects Versions: 18.0.1.Final, 19.1.0.Final, 20.0.0.Beta1 > Reporter: Konrad Bak > Assignee: Flavia Rainone > Priority: Blocker > Fix For: 20.0.0.Final > > > https://github.com/konbk/bug-report-wildfly-oome > The project shows a huge memory leak introduced in recent WildFly versions that can crash a real-world Java EE application in a matter of hours. > When a JSF page contains any component bound to page variable, all CDI beans (regardless of scope) used on that page stay in memory. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 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 June 2020