Re: [VFS] Encoded dots, trailing slash, and PR 543
I responded on the PR: while I agree the PR fixes a few cases, there are more issues in this part of the codebase. Earlier[0], I changed UriParser.normalisePath to support URI-encoded characters, as that seemed like the least invasive change to fix the particular issue I was dealing with back then. However, looking closer at the code now, I see more places that would need to be updated to support those reliably. I now think we should simplify the code by converting those URI-encoded characters already in UriParser.fixSeparators, instead of trying to support them later on. This has a somewhat larger risk of changing behaviour and breaking existing code, but reduces the risk of remaining bugs in this area. I tried this out quickly in [1] and the (fairly extensive) set of unit tests accepts it. Arnout [0]: https://github.com/apache/commons-vfs/pull/396 [1]: https://github.com/apache/commons-vfs/pull/555 On Sun, Jun 16, 2024 at 1:39 PM Gary Gregory wrote: > Hi All, > > PR https://github.com/apache/commons-vfs/pull/543/files claims to > resolve 2 issues. > > I want feedback from this list, please. > > TY! > Gary > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Arnout Engelen ASF Security Response Apache Pekko PMC member, ASF Member NixOS Committer Independent Open Source consultant
Re: [ALL] GitHub is done with Java 8
Really? https://adoptium.net/temurin/releases/?version=8 seems to have recent versions. setup-java seems to be treating it as a bug at this time: https://github.com/actions/setup-java/issues/625 On Wed, Apr 24, 2024 at 4:12 PM Slawomir Jaranowski wrote: > Hi, > > Temurin jdk distribution doesn't support JDK 8. You can try with zulu. > > śr., 24 kwi 2024 o 15:57 Gary D. Gregory napisał(a): > > > Hi All, > > > > I just saw this on GitHub for our Lang component: > > > > Error: Could not find satisfied version for SemVer '8'. > > > > Available versions: 22.0.1+8, 22.0.0+36, 21.0.3+9.0.LTS, 21.0.2+13.0.LTS, > > 21.0.1+12.0.LTS, 21.0.0+35.0.LTS, 20.0.2+9, 20.0.1+9, 20.0.0+36, > 19.0.2+7, > > 19.0.1+10, 19.0.0+36, 18.0.2+101, 18.0.2+9, 18.0.1+10, 18.0.0+36, > > 17.0.11+9, 17.0.10+7, 17.0.9+9, 17.0.8+101, 17.0.8+7, 17.0.7+7, > 17.0.6+10, > > 17.0.5+8, 17.0.4+101, 17.0.4+8, 17.0.3+7, 17.0.2+8, 17.0.1+12, 17.0.0+35, > > 11.0.23+9, 11.0.22+7.1, 11.0.22+7, 11.0.21+9, 11.0.20+101, 11.0.20+8, > > 11.0.19+7, 11.0.18+10, 11.0.17+8, 11.0.16+101, 11.0.16+8, 11.0.15+10 > > > > So it looks like goodbye Java 8 on GitHub. > > > > Gary > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > -- > Sławomir Jaranowski > -- Arnout Engelen ASF Security Response Apache Pekko PMC member, ASF Member NixOS Committer Independent Open Source consultant
Re: [VOTE] Release Apache Commons Compress 1.26.0 based on RC1
el Version 23.3.0: Wed Dec 20 21:28:58 > PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64 > > Details of changes since 1.25.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/compress/1.26.0-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/compress/1.26.0-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/compress/1.26.0-RC1/site/index.html > (note some *relative* links are broken and the 1.26.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 1.25.0): > > https://dist.apache.org/repos/dist/dev/commons/compress/1.26.0-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/compress/1.26.0-RC1/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > For following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-compress.git > --branch > <https://gitbox.apache.org/repos/asf/commons-compress.git--branch> > commons-compress-1.26.0-RC1 commons-compress-1.26.0-RC1 > cd commons-compress-1.26.0-RC1 > > 1b) Download and unpack the source archive from: > > https://dist.apache.org/repos/dist/dev/commons/compress/1.26.0-RC1/source > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which > you then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page > which you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page > which you then must check. > > mvn install -DskipTests -P japicmp japicmp:cmp > > 4) Build the package > > mvn -V clean package > > You can record the Maven and Java version produced by -V in your VOTE > reply. > To gather OS information from a command line: > Windows: ver > Linux: uname -a > > 5) Build the site for a single module project > > Note: Some plugins require the components to be installed instead of > packaged. > > mvn site > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > -the end- > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Arnout Engelen ASF Security Response Podling Project Management Committee member on Apache Pekko Committer on NixOS Independent Open Source consultant
Re: Security model for Commons Imaging, Compress, Codec and IO: RCE and DOS?
On Thu, Dec 14, 2023 at 2:00 PM Elliotte Rusty Harold wrote: > On Thu, Dec 14, 2023 at 6:09 AM Arnout Engelen wrote: > > * I'd say parsing/decompression/decoding should never allow malicious > input > > to trigger arbitrary code execution(?) > > Do any of these products include native libraries/C code? To the > extent it's pure Java, arbitrary code execution indicates a bug in the > JDK. > Beyond that, I do not think Apache Commons (or anyone else) should > expect *any* input to be correctly validated/sanitized. All products > should be robust against arbitrary byte streams. Malformed input > should be detected and an appropriate exception thrown. > Examples of what I referred to as arbitrary code execution would be unbounded deserialization of untrusted data (via techniques like those described in the motivation for https://docs.oracle.com/en/java/javase/17/core/serialization-filtering1.html ) or (directly or indirectly) passing untrusted input to functions such as "Runtime.exec()". I guess we can debate the word 'arbitrary', but it sounds like you're saying *none* of the Apache Commons libraries should allow triggering those? > Excessive resource usage is a separate question since it can be > triggered by valid input without escaping the VM protections. Proper > input validation protects against some but not all resource exhaustion > attacks. > I agree completely avoiding all exhaustion attacks is probably unfeasible - framing it as "'disproportionate' resource usage" was intended to give us some wiggle room to treat clearly-problematic behaviour as a bug/vulnerability while not taking it to extremes. -- Arnout Engelen ASF Security Response Committer on Apache Pekko Committer on NixOS Independent Open Source consultant
Security model for Commons Imaging, Compress, Codec and IO: RCE and DOS?
Hello Commons developers, I'd like to discuss what our security ambitions are for components like Commons Imaging, Compress, Codec and IO: Generally for Commons, we say that unless otherwise specified it is up to the user of the library to make sure any input is either trusted or correctly validated/sanitized (https://commons.apache.org/security.html). For these modules it might make sense to be a little more nuanced: https://commons.apache.org/proper/commons-imaging/ already explicitly says it intends to be "more secure against corrupt/malicious images", and while the others don't seem to say it explicitly AFAICS in practice we consider it OK to decompress/decode/... untrusted input at least to some degree. So what does that mean? * I'd say parsing/decompression/decoding should never allow malicious input to trigger arbitrary code execution(?) * Should parsing/decompression/decoding protect against 'disproportionate' CPU usage? * Should parsing/decompression/decoding protect against 'disproportionate' memory usage? * Should parsing/decompression/decoding protect against 'disproportionate' disk usage? Where we say 'yes', we should also decide whether we intend to treat such issues as security problems (that should be fixed with some priority and, after release, disclosed in an advisory) or bugs/improvements (where we can possibly take more of an 'issues and patches welcome' position). I'm curious about your thoughts! -- Arnout Engelen ASF Security Response Committer on Apache Pekko Committer on NixOS Independent Open Source consultant
Re: Improve vulnerability reporting
(dropping security@c.a.o to avoid cross-posting between private and public lists) On Sat, Jul 15, 2023 at 6:26 PM wrote: > as suggested in the comments on > https://issues.apache.org/jira/browse/IMAGING-354 I am now raising this > issue here instead. > Thanks for sharing your experience! > In summary, I tried reporting a potential security vulnerability to the > maintainers of Commons Imaging in the past, and at least in my opinion > the communication was not ideal. I know which issue you are referring to. Unfortunately, the reason we haven't provided you with progress updates on it, is because there hasn't _been_ much progress on it. The response time has been longer than we'd like here. This is in part because Apache Commons is a wide-ranging project, and security issues are initially only shared within the Commons Security group. Sometimes it can take a while to find someone with the time, energy and expertise to pick up a particular issue. If you have any time to (privately) contribute to the solution of this issue yourself that would of course be warmly appreciated. In my opinion it would be great to > consider additional / alternative ways to sending vulnerability reports > per mail because you cannot track progress there properly at all, and > you constantly have to keep the issue in the back of your head fearing > that otherwise it might just be forgotten. > Luckily, if you have received our confirmation of the issue, this means we are internally tracking it and it will not be forgotten on our side. As was clearly the case here, that is unfortunately no guarantee that it will be resolved quickly - that will not change by changing the reporting mechanism. That said, allowing vulnerability reports to be provided through alternative ways (such as GitHub Private Vulnerability Reporting) is definitely on our radar. We're working out some challenges to fit it into the rest of our workflow, though, and it will depend on the project whether they choose to use it. Kind regards, -- Arnout Engelen ASF Security Response
Re: Publish statement on Commons Text CVE
On Wed, Oct 19, 2022 at 12:23 PM Gary Gregory wrote: > Would you be available to update the Commons Configuration page > > https://github.com/apache/commons-configuration/blob/master/src/site/xdoc/security.xml > in the same way you did for Commons Text? The CVE is basically the > same: https://nvd.nist.gov/vuln/detail/CVE-2022-33980 > Happy to! Proposed https://github.com/apache/commons-configuration/pull/230 Kind regards, Arnout On Tue, Oct 18, 2022 at 11:20 PM Gary Gregory > wrote: > > > > FYI: I updated the security page > > https://commons.apache.org/proper/commons-text/security.html > > > > Gary > > > > On Tue, Oct 18, 2022 at 4:25 PM Gary Gregory > wrote: > > > > > > I have an unpublished security page in the repo already. Let's not > duplicate information like this PR does please. Publishing a non-snapshot > site is a pain and I don't want to do more than I have to. There is no need > to buy in and promote the FUD on the front page IMO. This component will > soon publish a security page and you can PR that page ( > https://github.com/apache/commons-text/blob/master/src/site/xdoc/security.xml) > if you want to update the details. > > > > > > TY! > > > > > > On Tue, Oct 18, 2022, 09:52 Arnout Engelen wrote: > > >> > > >> Hello Commons, > > >> > > >> As you might know Commons Text recently published a CVE. It seems > there is > > >> a fair bit of confusion about its severity online, so it seems like a > good > > >> idea to publish a statement around that on the website. > > >> > > >> I've proposed one at https://github.com/apache/commons-text/pull/374 > and > > >> I'd like to ask for your review & help publishing. Given the issue is > > >> getting some attention it might be nice to publish something soon and > maybe > > >> refine it later ;). I'll also publish it at > > >> https://blogs.apache.org/security . > > >> > > >> I think what would need to happen is: > > >> * review and merge https://github.com/apache/commons-text/pull/374 > > >> * check out the commit before the merge commit (since that one still > has > > >> 1.10.0 as the version in the pom.xml) > > >> * tag it with something clear, like > "commons-text-1.10.0-docs-update"(?) > > >> * push the tag > > >> * do a 'mvn site:deploy' > > >> > > >> Much appreciated! > > >> > > >> > > >> Kind regards, > > >> > > >> Arnout >
Publish statement on Commons Text CVE
Hello Commons, As you might know Commons Text recently published a CVE. It seems there is a fair bit of confusion about its severity online, so it seems like a good idea to publish a statement around that on the website. I've proposed one at https://github.com/apache/commons-text/pull/374 and I'd like to ask for your review & help publishing. Given the issue is getting some attention it might be nice to publish something soon and maybe refine it later ;). I'll also publish it at https://blogs.apache.org/security . I think what would need to happen is: * review and merge https://github.com/apache/commons-text/pull/374 * check out the commit before the merge commit (since that one still has 1.10.0 as the version in the pom.xml) * tag it with something clear, like "commons-text-1.10.0-docs-update"(?) * push the tag * do a 'mvn site:deploy' Much appreciated! Kind regards, Arnout
