This is an automated email from the ASF dual-hosted git repository.
ggregory pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/commons-fileupload.git
The following commit(s) were added to refs/heads/master by this push:
new 3195578 Fix grammar, spelling, wording
3195578 is described below
commit 319557854e1e5e15454f9d114dfc8db97e8e1051
Author: Gary Gregory <garydgreg...@gmail.com>
AuthorDate: Mon Apr 10 19:09:59 2023 -0400
Fix grammar, spelling, wording
Pick up checksyle plugin version from parent
No CLIRR check on a major version
---
pom.xml | 22 ++++------------------
src/site/xdoc/security-reports.xml | 34 ++++++++++++++--------------------
2 files changed, 18 insertions(+), 38 deletions(-)
diff --git a/pom.xml b/pom.xml
index 1ca1c35..68f5e5c 100644
--- a/pom.xml
+++ b/pom.xml
@@ -236,12 +236,13 @@
<commons.osgi.import>!javax.portlet,*</commons.osgi.import>
<commons.osgi.dynamicImport>javax.portlet</commons.osgi.dynamicImport>
<japicmp.skip>true</japicmp.skip>
+ <clirr.skip>true</clirr.skip>
<moditect-maven-plugin.version>1.0.0.RC2</moditect-maven-plugin.version>
<moditect.skip>true</moditect.skip>
<!-- Commons Release Plugin -->
- <commons.bc.version>1.3.3</commons.bc.version>
- <commons.rc.version>RC2</commons.rc.version>
+ <commons.bc.version>2.0.0</commons.bc.version>
+ <commons.rc.version>RC1</commons.rc.version>
<commons.release.isDistModule>true</commons.release.isDistModule>
<commons.distSvnStagingUrl>scm:svn:https://dist.apache.org/repos/dist/dev/commons/${commons.componentid}</commons.distSvnStagingUrl>
<commons.releaseManagerName>Rob Tompkins</commons.releaseManagerName>
@@ -436,7 +437,7 @@
</plugin>
</plugins>
</pluginManagement>
- <defaultGoal>clean verify apache-rat:check clirr:check checkstyle:check
javadoc:javadoc spotbugs:check</defaultGoal>
+ <defaultGoal>clean verify apache-rat:check checkstyle:check
javadoc:javadoc spotbugs:check</defaultGoal>
</build>
<reporting>
@@ -460,7 +461,6 @@
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
- <version>${checkstyle.plugin.version}</version>
<configuration>
<configLocation>${basedir}/src/checkstyle/fileupload_checks.xml</configLocation>
<suppressionsLocation>${basedir}/src/checkstyle/checkstyle-suppressions.xml</suppressionsLocation>
@@ -478,20 +478,6 @@
</rulesets>
</configuration>
</plugin>
- <plugin>
- <groupId>org.codehaus.mojo</groupId>
- <artifactId>clirr-maven-plugin</artifactId>
- <version>${commons.clirr.version}</version>
- <configuration>
- <comparisonArtifacts>
- <comparisonArtifact>
- <groupId>commons-fileupload</groupId>
- <artifactId>commons-fileupload</artifactId>
- <version>1.3</version>
- </comparisonArtifact>
- </comparisonArtifacts>
- </configuration>
- </plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>taglist-maven-plugin</artifactId>
diff --git a/src/site/xdoc/security-reports.xml
b/src/site/xdoc/security-reports.xml
index 22ec4a8..09a2ab6 100644
--- a/src/site/xdoc/security-reports.xml
+++ b/src/site/xdoc/security-reports.xml
@@ -72,32 +72,26 @@
<subsection name="Notes on Apache Commons FileUpload 1.3.3">
<p>
- Regarding potential security problems with the class called
DiskFileItem,
- it is true, that this class exists, and can be
serialized/deserialized in FileUpload versions, up to, and
- including 1.3.2. It is also true, that a malicious attacker can
abuse this possibility to create abitraryly
- located files (assuming the required permissions) with arbitrary
contents, if he gets the opportunity to
- provide specially crafted data, which is being deserialized by a
Java application, which has either of the
- above versions of Commons FileUpload in the classpath, and which
puts no limitations on the classes being
- deserialized.
+ Up to, and including version 1.3.2, the class
org.apache.commons.fileupload2.disk.DiskFileItem can be serialized and
+ deserialized. A malicious attacker can abuse this feature to
arbitrarily create files with any content, assuming the
+ required permissions for a given file location. If an attacker
gets the opportunity to provide maliciously crafted data
+ and an application puts no limitations on classes being
deserialized, that data can then be deserialized by a Java
+ application.
</p>
<p>
- That being said, we (the Apache Commons team) hold the view, that
the actual problem is not the DiskFileItem
- class, but the "if" in the previous sentence. A Java application
should carefully consider, which classes
- can be deserialized. A typical approach would be, for example, to
provide a blacklist, or whitelist of
- packages, and/or classes, which may, or may not be deserialized.
+ We hold the view that the actual problem is not the DiskFileItem
class, but that a Java application should carefully
+ consider which classes can be deserialized. A typical approach
would be, for example, to provide a deny list, or an
+ accept list of packages, and/or classes, which may, or may not be
deserialized.
</p>
<p>
- On the other hand, we acknowledge, that the likelyhood of
application container vendors taking such a
- simple security measure is extremely low. So, in order to support
the Commons Fileupload users, we have
- decided to choose a different approach:
+ We acknowledge that the likelihood of application container
vendors taking such a simple security measure is extremely
+ low. In order to better support Commons Fileupload users, we chose
a different approach.
</p>
<p>
- Beginning with 1.3.3, the class DiskFileItem is still implementing
the interface java.io.Serializable.
- In other words, it still declares itself as serializable, and
deserializable to the JVM. In practice,
- however, an attempt to deserialize an instance of DiskFileItem
will trigger an Exception. In the unlikely
- case, that your application depends on the deserialization of
DiskFileItems, you can revert to the
- previous behavior by setting the system property
"org.apache.commons.fileupload.disk.DiskFileItem.serializable"
- to "true".
+ Starting with version 1.3.3, the class DiskFileItem still
implements the interface java.io.Serializable but attempts
+ to deserialize an instance of DiskFileItem will trigger an
Exception. In the unlikely case, that your application
+ depends on the deserialization of DiskFileItems, you can revert to
the previous behavior by setting the system property
+ "org.apache.commons.fileupload.disk.DiskFileItem.serializable" to
"true".
</p>
</subsection>
