Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade org.apache.commons.fileupload to latest version (1.4.0) #41

Closed
mknauer opened this issue Aug 3, 2022 · 3 comments · Fixed by #45
Closed

Upgrade org.apache.commons.fileupload to latest version (1.4.0) #41

mknauer opened this issue Aug 3, 2022 · 3 comments · Fixed by #45
Assignees
Labels
enhancement New feature or request releng Release engineering tasks
Milestone

Comments

@mknauer
Copy link
Contributor

mknauer commented Aug 3, 2022

Migration of Bugzilla bug 542478

The original bug reporter reported on 2018-12-06 10:49:46 EST ...

The result of a dependency check of our application (which is based on Eclipse RAP) showed a vulnerability in org.apache.commons.fileupload_1.3.2 with high severity and high confidence (CVE-2016-1000031). Therefore, I would like to request an upgrade of org.apache.commons.fileupload to the latest version (1.3.3) in RAP 3.7.

A detailed analysis (2018-12-11 06:29:59 EST) of the security issue in the mentioned library revealed that ...

RAP (org.eclipse.rap.fileupload bundle) is not using DiskFileItem. We are processing the input stream directly using FileItemStream (see FileUploadProcessor#handleFileUpload). That's why (...) we are not affected by the above vulnerability.

While the above ("RAP fileupload implementation is not affected by this vulnerability") is still true, we believe that an upgrade of org.apache.commons.fileupload is required in order to avoid false positives in security checks.

@mknauer mknauer added enhancement New feature or request releng Release engineering tasks labels Aug 3, 2022
@mknauer mknauer added this to the 3.22 milestone Aug 3, 2022
@mknauer mknauer self-assigned this Aug 3, 2022
@mknauer
Copy link
Contributor Author

mknauer commented Aug 3, 2022

Reading the 1.4 release notes I don't see any reason or incompatibility that would require to keep the older 1.3.3 version that was mentioned in the original bug report. Instead I would suggest to start upgrading to 1.4.

Additionally I believe there is no further IP check required for the library dependency upgrade in RAP Runtime. First, there is an already approved CQ 21543 available for another project in the files, second (and more important) according to the project handbook, ClearlyDefined is a trusted source of license information. By using the Eclipse Dash License Tool I get the following positive result for maven/mavencentral/commons-fileupload/commons-fileupload/1.4 from ClearlyDefined:

$ echo "maven/mavencentral/commons-fileupload/commons-fileupload/1.4" | java -jar org.eclipse.dash.licenses-0.0.1-20220803.055044-505.jar -
[main] INFO Querying Eclipse Foundation for license data for 1 items.
[main] INFO Found 0 items.
[main] INFO Querying ClearlyDefined for license data for 1 items.
[main] INFO Found 1 items.
[main] INFO Vetted license information was found for all content. No further investigation is required.

Unfortunately none of the clean versions are available for consumption from Eclipse Orbit, i.e. we need to find a good way to integrate this library in the RAP build process.

mknauer added a commit that referenced this issue Aug 24, 2022
The tests in CommonsFileUpload_Test were testing the API behaviour of
the upstream Apache `commons-fileupload` library only, and are not
specific to its usage in RAP. With the upcoming dependency upgrade
in #41 these tests started to fail because bugs such as FILEUPLOAD-258 [1]
are fixed. Removing the test class.

[1] https://issues.apache.org/jira/browse/FILEUPLOAD-258
mknauer added a commit that referenced this issue Aug 24, 2022
This change also includes Apache `commons-io` in version 2.11.0.

Update lower version boundaries of Apache `commons-fileupload` and
`commons-io` to the version of the updated bundles in order to ensure
that the correct versions are selected at runtime.

The new bundles are consumed from Eclipse Platform which retrieves them
from Maven Central. As part of this process, the bundle symbolic name of
the bundles changed:

- `org.apache.commons.fileupload` to `org.apache.commons.commons-fileupload`
- `org.apache.commons.io` to `org.apache.commons.commons-io`

Update features, demo launch configurations, and demo product
definitions to the new name.

This fixes #41.
@mknauer
Copy link
Contributor Author

mknauer commented Aug 24, 2022

The fix includes...

  • the update of org.apache.commons.fileupload 1.3.2 to org.apache.commons.commons-fileupload 1.4.0 and
  • the update of org.apache.commons.io 2.2 to org.apache.commons.commons-io 2.11.0.

Please note that the bundle symbolic name has changed because the new bundles are now consumed from Eclipse Platform which itself started to consume them directly from Maven Central.

@bwolff
Copy link

bwolff commented Sep 27, 2022

Hi,

I run into a Maven dependency resolution issue related to the version bump of commons-fileupload to 1.4.0 in my project. It seems the resulting POM dependency entry of org.apache.commons.fileupload looks like this:

<dependency>
  <groupId>commons-fileupload</groupId>
  <artifactId>commons-fileupload</artifactId>
  <version>1.4.0</version>
</dependency>

It refers to version 1.4.0, but the actual version of the commons-fileupload artefact is 1.4 (d'oh!). See: https://search.maven.org/artifact/commons-fileupload/commons-fileupload/1.4/jar

Maven treats versions 1.4 and 1.4.0 differently and fails to resolve the correct artefact from Maven central. The workaround is to declare a direct dependency to commons-fileupload in version 1.4.

I'm not sure how the pom.xml is generated, but it probably takes the information from the bundle dependencies, which afaik requires the use of the 3 part semvers, so there might be a version incompatibility between the bundle and Maven dependency worlds.

NB: I should mention that I'm experiencing this problem in a Gradle build and haven't tested it with a Maven build. However, since the version in the pom does not correspond to the artefact version in Maven central, other Maven builds might run into this issue as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request releng Release engineering tasks
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants