[JBoss JIRA] (JGRP-2285) ObjectMessage: handle objects with incorrect size
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2285?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2285.
----------------------------
Resolution: Rejected
> ObjectMessage: handle objects with incorrect size
> -------------------------------------------------
>
> Key: JGRP-2285
> URL: https://issues.redhat.com/browse/JGRP-2285
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> An ObjectMessage accepts objects of type SizeStreamable. When such an object has an incorrect serializableSize() method, the following can happen:
> * Say the serialized size is 1000, but serializedSize() returns 1200
> * When the ObjectMessage is serialized, a length of 1200 is written, but then only 1000 bytes are serialized onto the output stream
> * On the receiving side, length=1200 is read and a byte array of 1200 is created
> * DataInput.readFully() reads 1000 bytes, but then reaches the eof of the stream, trying to read an additional 200 bytes
> * An exception is thrown and the reading of the message fails
> If we caught the exception, things would work, however this would mask other errors in the object serialization/deserialization code.
> If the serialization code was able to mark the position of the output stream, then we could write the *actual number of bytes written* (especially if it differs from serializedSize()); however, DataOutput doesn't give us this option!
> Investigate whether simply catching (and ignoring) the EOFException would work.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (JGRP-2285) ObjectMessage: handle objects with incorrect size
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2285?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2285:
--------------------------------
Added {{ObjectMessageTest.testIncorrectSize()}}: as suspected above, this issue is moot, as the object is not preceeded with a length field.
> ObjectMessage: handle objects with incorrect size
> -------------------------------------------------
>
> Key: JGRP-2285
> URL: https://issues.redhat.com/browse/JGRP-2285
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> An ObjectMessage accepts objects of type SizeStreamable. When such an object has an incorrect serializableSize() method, the following can happen:
> * Say the serialized size is 1000, but serializedSize() returns 1200
> * When the ObjectMessage is serialized, a length of 1200 is written, but then only 1000 bytes are serialized onto the output stream
> * On the receiving side, length=1200 is read and a byte array of 1200 is created
> * DataInput.readFully() reads 1000 bytes, but then reaches the eof of the stream, trying to read an additional 200 bytes
> * An exception is thrown and the reading of the message fails
> If we caught the exception, things would work, however this would mask other errors in the object serialization/deserialization code.
> If the serialization code was able to mark the position of the output stream, then we could write the *actual number of bytes written* (especially if it differs from serializedSize()); however, DataOutput doesn't give us this option!
> Investigate whether simply catching (and ignoring) the EOFException would work.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFWIP-342) RESTEasy JAXB end-point on bootable jar return unexpected 400 response
by Marek Kopecky (Jira)
Marek Kopecky created WFWIP-342:
-----------------------------------
Summary: RESTEasy JAXB end-point on bootable jar return unexpected 400 response
Key: WFWIP-342
URL: https://issues.redhat.com/browse/WFWIP-342
Project: WildFly WIP
Issue Type: Bug
Reporter: Marek Kopecky
Assignee: Jean Francois Denise
RFE link: EAP7-1385
RESTEasy JAXB end-point on bootable jar return unexpected 400 response with these security params:
{code:xml}
<context-param>
<param-name>resteasy.document.secure.processing.feature</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>resteasy.document.secure.disableDTDs</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>resteasy.document.expand.entity.references</param-name>
<param-value>false</param-value>
</context-param>
{code}
Used layers:
* jaxrs-server
* microprofile-config
Although this test is security related, AFAIK this is not related with legacy-security/elytron configuration, because related params are used in javax.xml.parsers.DocumentBuilderFactory directly from RESTEasy. Anyway let me know if I'm wrong.
Steps to reproduce:
# use installed WF version with reasonable layers, eg: WF_VERSION=21.0.0.Beta1-SNAPSHOT #
# git clone git@github.com:marekkopecky/Resteasy.git -b bootable-jar-3-12-secure-processing
# cd Resteasy
# mvn install -DskipTests -Dcheckstyle.skip=true
# cd testsuite
# mvn install:install-file -Dpackaging=pom -Dfile=pom.xml -DpomFile=pom.xml
# cd integration-tests
# mvn clean install -Dts.bootable -Ddefault=false -Ddisable.microprofile.tests -Dserver.version=${WF_VERSION} -Dserver.home=placeholder -Dcheckstyle.skip=true -Denforcer.skip -Dcheckstyle.skip=true -Dmaven.test.redirectTestOutputToFile=false
I can move these steps outside of TS, but I believe that TS doesn't affects this bootable jar behaviour, so it doesn't seem to be necessary.
I see just this unexpected&suspicious console output although I'm not sure whether it's related or not:
{noformat}
[org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 189; External DTD: Failed to read external DTD 'SecureProcessing_external.dtd', because 'file' access is not allowed due to restriction set by the accessExternalDTD property.]
{noformat}
cc: [~fburzigo], [~yersan], [~asoldano], [~ron_sigal]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFLY-13818) Increase the test coverage of LayersTestCase for the all layers case
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13818:
---------------------------------------
Summary: Increase the test coverage of LayersTestCase for the all layers case
Key: WFLY-13818
URL: https://issues.redhat.com/browse/WFLY-13818
Project: WildFly
Issue Type: Task
Components: Build System, Test Suite
Reporter: Yeray Borges Santana
Assignee: Yeray Borges Santana
Fix For: 21.0.0.Beta1
The LayersTestCase verifies the following:
* Verifies the provisioned modules are the expected ones.
* Verifies the provisioned server starts successfully.
Currently, we have a server provision under test that doesn't add all the layers, the idea of this task is to supply one server provisioning including all the available layers.
The WildFly Galleon Layers have an inheritance structure where some layers already include others, instead of check what is already included, the idea on this task is to include all, even if they are already included by another one, Galleon will take care of merging them. In the future, when a new layer is added, we have to add to this all-in-one provision.
The idea is to have one all-in-one provision for jpa and all-in-one provision for jpa-distribute. The similar task could be done if we detect additional mutually excludable layers.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years