Re: [DRAFT][REPORT] September 2023
You could add that we had a successful participant in Google Summer of Code 2023 working on the statistics sub-project. This may apply to the community section. Alex On Wed, 13 Sept 2023 at 02:59, Gary Gregory wrote: > > Here is the report I plan on filing, probably in the AM (EST): > > ## Description: > The mission of Apache Commons is the creation and maintenance of Java-focused > reusable libraries and components. > > ## Project Status: > Current project status: Ongoing with moderate activity. > Issues for the board: None. > > ## Membership Data: > Apache Commons was founded 2007-06-19 (16 years ago) > There are currently 149 committers and 42 PMC members in this project. > The Committer-to-PMC ratio is roughly 5:2. > > Community changes, past quarter: > - No new PMC members. Last addition was Matt Juntunen on 2021-06-25. > - No new committers. Last addition was Claude Warren on 2022-02-01. > > ## Project Activity: > Our recent releases are: > - COMPRESS-1.24.0 was released on 2023-09-08. > - PARENT-62 was released on 2023-09-05. > - DBCP-2.10.0 was released on 2023-09-03. > - PARENT-61 was released on 2023-08-29. > - PARENT-60 was released on 2023-08-23. > - DBUTILS-1.8.0 was released on 2023-08-08. > - LANG-3.13.0 was released on 2023-07-28. > - PARENT-59 was released on 2023-07-26. > - FILEUPLOAD-2.0.0-M1 was released on 2023-07-19. > - BUILD-PLUGIN-1.13 was released on 2023-06-28. > - RELEASE-PLUGIN-1.8.1 was released on 2023-06-28. > - CODEC-1.16.0 was released on 2023-06-21. > > ## Community Health: > We have had much more activity on the mailing lists, Jira, and GitHub. We are > also reviewing security reports as they come in and have been working through > that backlog. > > Gary > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DRAFT][REPORT] September 2023
I most certainly will! Thank you! Gary PS: The Commons "Project" is made of "Components". I'm pretty sure Apache does not have the formal concept of "Sub-projects" :-) On Wed, Sep 13, 2023 at 3:18 AM Alex Herbert wrote: > > You could add that we had a successful participant in Google Summer of > Code 2023 working on the statistics sub-project. This may apply to the > community section. > > Alex > > On Wed, 13 Sept 2023 at 02:59, Gary Gregory wrote: > > > > Here is the report I plan on filing, probably in the AM (EST): > > > > ## Description: > > The mission of Apache Commons is the creation and maintenance of > > Java-focused > > reusable libraries and components. > > > > ## Project Status: > > Current project status: Ongoing with moderate activity. > > Issues for the board: None. > > > > ## Membership Data: > > Apache Commons was founded 2007-06-19 (16 years ago) > > There are currently 149 committers and 42 PMC members in this project. > > The Committer-to-PMC ratio is roughly 5:2. > > > > Community changes, past quarter: > > - No new PMC members. Last addition was Matt Juntunen on 2021-06-25. > > - No new committers. Last addition was Claude Warren on 2022-02-01. > > > > ## Project Activity: > > Our recent releases are: > > - COMPRESS-1.24.0 was released on 2023-09-08. > > - PARENT-62 was released on 2023-09-05. > > - DBCP-2.10.0 was released on 2023-09-03. > > - PARENT-61 was released on 2023-08-29. > > - PARENT-60 was released on 2023-08-23. > > - DBUTILS-1.8.0 was released on 2023-08-08. > > - LANG-3.13.0 was released on 2023-07-28. > > - PARENT-59 was released on 2023-07-26. > > - FILEUPLOAD-2.0.0-M1 was released on 2023-07-19. > > - BUILD-PLUGIN-1.13 was released on 2023-06-28. > > - RELEASE-PLUGIN-1.8.1 was released on 2023-06-28. > > - CODEC-1.16.0 was released on 2023-06-21. > > > > ## Community Health: > > We have had much more activity on the mailing lists, Jira, and GitHub. We > > are > > also reviewing security reports as they come in and have been working > > through > > that backlog. > > > > Gary > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
CVE-2023-42503: Apache Commons Compress: Denial of service via CPU consumption for malformed TAR file
Severity: moderate Affected versions: - Apache Commons Compress 1.22 before 1.24.0 Description: Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. Users are recommended to upgrade to version 1.24.0, which fixes the issue. A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. [1]: https://issues.apache.org/jira/browse/COMPRESS-612 [2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 [3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html [4]: https://bugs.openjdk.org/browse/JDK-6560193 [5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. Credit: Yakov Shafranovich, Amazon Web Services (reporter) References: https://commons.apache.org/ https://www.cve.org/CVERecord?id=CVE-2023-42503 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
VFS Questions
I was looking at the VFS code recently and had a few questions: - There's a *plugins.xml* file that each of the plugins needs to register themselves with. I was wondering if there was a reason that the *ServiceLoader* wasn't used for this? It would seem like a natural fit. - Are there any plans to create adaptors for the NIO FS package? I'm envisioning something where we write adapters that adapt the interfaces of one to the interfaces of the other. This might cut down on the amount of work, since every implementation would not have to write their own NIO FS adapter. - Is there a TCK for VFS? This would make it easy for implementers to verify that they're conforming with the intent of the interfaces. This came up while I was looking over the S3 implementation and realised that the UserAuthenticator doesn't seem to be implemented. And that credentials are basically part of the URL. Ideally, the TCK would allow the user to specify a ROOT URL, and user credentials, and then run the suite of tests and verify that all operations work properly. - What is the long-term plan for VFS? Do you want to have all of the implementations be NIO FS implementations, and the original APIs for VFS would be deprecated? The reason I ask is that we have an application that currently uses VFS with a handful of plugins and want to know if we should plan on refactoring that at some point to NIO FS? Cheers, Mark
Re: VFS Questions
Hello, On Wed, Sep 13, 2023 at 5:57 PM Mark Fortner wrote: > > I was looking at the VFS code recently and had a few questions: > >- There's a *plugins.xml* file that each of the plugins needs to >register themselves with. I was wondering if there was a reason that the >*ServiceLoader* wasn't used for this? It would seem like a natural fit. VFS was created before service loaders and never migrated. Migrating to service loaders might create compatibility issues, maybe with class loaders, who knows... >- Are there any plans to create adaptors for the NIO FS package? Yes, I have a branch for that in my private repo. It's on my to-do list for sure. > I'm >envisioning something where we write adapters that adapt the interfaces of >one to the interfaces of the other. This might cut down on the amount of >work, since every implementation would not have to write their own NIO FS >adapter. >- Is there a TCK for VFS? Yes, kind of, the unit tests are built within their own testing mini-framework, it's not great but it's what we have. It desperately needs porting from it's JUnit 3 roots to JUnit 5. >This would make it easy for implementers to >verify that they're conforming with the intent of the interfaces. This came >up while I was looking over the S3 implementation and realised that the >UserAuthenticator doesn't seem to be implemented. And that credentials are >basically part of the URL. Ideally, the TCK would allow the user to specify >a ROOT URL, and user credentials, and then run the suite of tests and >verify that all operations work properly. >- What is the long-term plan for VFS? My plan is: - port unit tests to JUnit 5 - interoperation with NIO - modularize such that each file system is in its own Maven module > Do you want to have all of the >implementations be NIO FS implementations, and the original APIs for VFS >would be deprecated? No. If you like the VFS API, you should be able to keep on using it. > The reason I ask is that we have an application that >currently uses VFS with a handful of plugins and want to know if we should >plan on refactoring that at some point to NIO FS? The above said, once NIO is supported, people can decide which they like best and we'll see what kind of feedback we get. HTH, Gary > > > Cheers, > > Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
