Re: [beanutils] Should Commons BeanUtil types implement Serializable
+1 Please include an example (or pseudocode) for people of a serialization proxy, since not all readers may be familiar with Bloch or his book. On Tue, Sep 3, 2024 at 11:54 AM Melloware Inc wrote: > +1 from me. > > On Tue, Sep 3, 2024 at 12:51 PM Gary D. Gregory > wrote: > > > Hi All, > > > > Considering the long history of problematic Serializable implementations > > throughout the Java ecosystem, not just in Commons, I propose that no > > BeanUtils types implement Serializable in the upcoming new major version > > 2.0. > > > > Instead, we would document that if you want to serialize objects, you > > should implement a serialization proxy as suggested in Effective Java by > > Joshua Bloch. > > > > The alternative would be to write a large amounts of tests to insure no > > security issues occur on top of fixing all read/write security bugs like > > BEANUTILS-556 [1]. > > > > WDYT? > > > > [1] https://issues.apache.org/jira/browse/BEANUTILS-556 > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > -- > == > Melloware > melloware...@gmail.com > http://melloware.com > == >
Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats
On Wed, May 29, 2024 at 8:17 AM Gary Gregory wrote: > (Sorry for the top post, phone) > > A case I can imagine an empty '' occurring is when the format string itself > is built programmatically for example a '%s' or using string concatenate of > a variable that holds a string where that string can be empty or an "s" to > mark a plural or a quote for example. > > "He said '" + bla + "' to me and I waited mm minutes!" > > Far fetched? Sure 😀 > > Gary > > On Wed, May 29, 2024, 8:43 AM sebb wrote: > > > On Sun, 26 May 2024 at 23:37, sebb wrote: > > > > > > On Sun, 26 May 2024 at 08:25, Laertes Moustakas > > wrote: > > > > > > > > Hello Gary, > > > > > > > > Thank you for your response. Some of the new assertions indeed fail > > when interpreting the duplicate single quote as an escaped quote instead > of > > a closing and opening quote. In particular, "y' ''years' M 'months'" is > > interpreted as "4 'years 0 months" while the expected text lacks the > quote > > before "years". Same for "hello''world": it's interpreted as > "hello'world" > > instead of "helloworld". > > > > > > Please see https://github.com/apache/commons-lang/pull/1227 for an > > > alternate solution. > > > This does not cause issues with any existing tests. > > > > > > However, it does change the behaviour of a duplicate single quote > > > which is found outside an existing opening and closing quote. > > > Instead of the empty string, it generates a lone single quote. > > > > > > Whilst this is a change in behaviour, it seems to me that there should > > > be no need for anyone to use a format that uses a pair of adjacent > > > single quotes to generate an empty string in the output, so it seems > > > unlikely that this will cause any breakages. > > > > I've since realised that this argument could also apply to the > > existing test cases: is there really a use-case for adjacent constant > > strings? > > Why would anyone want to split a constant string in this way? This is similar to allowable string concatenation in Python, which static analysis flags as a warning and probable bug. https://pylint.pycqa.org/en/latest/user_guide/messages/warning/implicit-str-concat.html > > AFAICT it just makes it harder to read the string. > > > > i.e. do the test cases represent a real-world use case? > > > > > > I understand this brings forth a breaking change in formats that use > > two single quotes to close and open new literals (or even add an empty > > string), but this is consistent with what java.text.SimpleDateFormat > > expects. And I believe that most developers would favor consistency > between > > format strings in equivalent classes. Thus, I think the cases described > > above where the two single quotes terminate and begin a literal should no > > longer be supported. > > > > I agree. > > > > My alternate solution avoids breaking the test cases, but the downside > > is that the syntax is not in agreement with > > java.text.SimpleDateFormat, and is more verbose where a single-quote > > is to be inserted in an existing constant string (it requires 4 single > > quotes, rather than 2). > > > > > > > > > > Should this change go forward, I expect it to be part of a major > > release (e.g. version 4.0.0, 5.0.0, etc.) instead of 3.x.x, as it does > > contain a breaking change. > > > > > > > > If you have more questions, please don't hesitate to contact me. > > > > > > > > Best regards, > > > > Laertes > > > > > > > > On 2024/05/25 13:47:23 Gary Gregory wrote: > > > > > Hello Laertes, > > > > > > > > > > Thank you for your interest in improving Apache Commons Lang :-) > > > > > > > > > > Do you foresee any compatibility issues for existing call sites and > > > > > format strings? > > > > > > > > > > For example, can you make your use cases work and still support: > > > > > > > > > > > > > https://github.com/apache/commons-lang/blob/d861f1b2116a41a45949d1401785220119a57e56/src/test/java/org/apache/commons/lang3/time/DurationFormatUtilsTest.java#L463-L473 > > > > > > > > > > Or, should these cases no longer be supported? > > > > > > > > > > TY! > > > > > Gary > > > > > > > > > > On Fri, May 24, 2024 at 4:15 PM Laertes Moustakas > > > wrote: > > > > > > > > > > > > Greetings, > > > > > > > > > > > > org.apache.commons.lang3.time.DurationFormatUtils contains useful > > methods > > > > > > to format a duration or period of milliseconds in the textual > > > > > > representation given by the format argument. It even allows > > arbitrary text > > > > > > to be printed between single quotes, on the condition that any > > opening > > > > > > single quotes will eventually close with another single quote. > > > > > > > > > > > > For example, > > > > > > DurationFormatUtils.formatDuration(64000L, "mm:ss") > > > > > > will return "01:04". > > > > > > > > > > > > While > > > > > > DurationFormatUtils.formatDuration(1804000L, "m'min' s'sec'") > > > > > > will yield "34min 4sec". > > > > > > > > > > > > However, as per the JavaDoc page for this class > > > > >
Re: Security model for Commons Imaging, Compress, Codec and IO: RCE and DOS?
On Thu, Dec 14, 2023 at 8:31 AM Arnout Engelen wrote: > 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? > > To this question specifically, I try to think about what we would expect a reasonable user to do. If we tell users that they need to check their inputs to prevent something like this, then the natural next question is “how?” If I was using an imaging or compression library that told me I needed to use an additional library to protect myself against malicious (just example) png or zip, then I’d wonder about the value of this library in the first place. The image library is supposed to know better how to handle png than I can. I guess I don’t have a solution or delineation but simply saying that you must validate your inputs before seems like mostly a hand wave approach that doesn’t reflect reality > 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 >
Re: [ALL] Change to GitHub Workflow message subjects
But often [VOTE] and [RESULT] are send with the same otherwise subject (and sometimes even [DISCUSS] before the vote, on other projects) On Thu, Oct 5, 2023 at 11:43 AM sebb wrote: > On Thu, 5 Oct 2023 at 17:25, Gary Gregory wrote: > > > > Should we use (VOTE) instead of [VOTE]? > > I doubt that is necessary. > > The GMail behaviour particularly affects the Workflow messages because > the same workflow names are re-used, so often the only differentiator > was the [component_repo] > e.g. > [GitHub] [commons-pool]: Workflow run "Java CI" is working again! > [GitHub] [commons-lang]: Workflow run "Java CI" is working again! > > Vote subjects include the component name in plain text. > > > Gary > > > > > > On Thu, Oct 5, 2023, 10:53 AM sebb wrote: > > > > > I discovered recently that GMail conversation mode ignores certain > > > subject prefixes when deciding which emails are in the same thread. > > > > > > In particular, it ignores text in [brackets]; as these were used to > > > enclose the repo name, this resulted in merging emails from different > > > components. > > > > > > The email subjects have been adjusted to use (parentheses) instead of > > > [brackets] so GMail should no longer merge mails from different > > > components. > > > > > > Sebb > > > > > > - > > > 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: [EMAIL] Fluent interface
I think the natural next question is whether we can have a major version change? Mike On Fri, Sep 29, 2023 at 6:24 AM sebb wrote: > On Fri, 29 Sept 2023 at 12:13, Filip Strajnar > wrote: > > > > Greetings, > > > > > > I've noticed that some methods on the org.apache.commons.mail.Email > > class provide fluent interface (examples include setCc, addBcc, > > addReplyTo), and some do not (to name a few: setAuthentication, > > setSmtpPort, setMailSession). Is this intentional, or am I allowed to > > submit a PR that would change all relevant void methods so that they > > would return an Email object instead? > > The return type is part of the Java method signature. > > Changing it would affect binary compatibility, so would not be > possible without a major version change. > > > > > Sincerely, > > > > Filip Strajnar > > > > > > - > > 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 > >
[security] finding known issues for commons projects
Hello commons-dev! I found the very lovely https://commons.apache.org/security.html page and I very much appreciate the links out to individual project's security pages. However, it looks like a little under half (9/21) have security pages linked. Does this mean that the other 12 projects have never had a security vulnerability reported? Reported but rejected? Reported and triaged in other ways - e.g. patched but not assigned a CVE? Any insight into the practices of the community is appreciated! Thanks, Mike - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move NO algorithms from ANY projects to math libraries
Can we move implementations, have old definitions be thin proxies to the new locations, mark existing methods as deprecated, and document that future development happens somewhere else? On Mon, Jul 17, 2023 at 9:55 AM sebb wrote: > On Mon, 17 Jul 2023 at 14:31, Elliotte Rusty Harold > wrote: > > > > On Mon, Jul 17, 2023 at 9:21 AM Dimitrios Efthymiou > > wrote: > > > > > > hello. I never said to redesign APIs. I only said that we can > > > move math algorithms from non-math projects, to the math projects > > > > > > > No, don't do that. > > > > Method signatures must not change. > > Class names must not change. > > Package names must not change. > > Group and artifact IDs must not change. > > Split packages are not allowed. > > +1 > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.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 > >
Re: [jxpath] reported CVE and path forward
Thanks for this outline, Mark. Some questions in line. Mike On Tue, Oct 11, 2022 at 6:13 AM Mark Thomas wrote: > Roman - don't do anything yet. > > Commons folk, I suggest the following which is based on how we have > oss-fuzz setup on Tomcat. > > 1. Create a Google account for fuzz-testing@c.a.o > 2. Put the password for the account in the PMC private shared repo so > any PMC member can access these reports. > If the dashboard doesn't support groups then maybe this is the only way. Otherwise I think it would be very nice if we could use ASF committer info or possibly github info since that often has mirrored groups of our internal organizational structure. > 3. Get Roman to add this account to the JXPath oss-fuzz project and the > projects for any other Commons components they have set up > Maybe it makes sense to group all of the apache-commons-* projects under the general apache-commons module at https://github.com/google/oss-fuzz/tree/master/projects/ That module is the one that was initially set up, including compress and imaging as mentioned by Matt S upthread. > 4. Review the reports once we have access via fuzz-testing@c.a.o (I'll > volunteer to help with this as I have some experience from Tomcat which > should speed things up) > I would be happy to volunteer. > 5. Ask the ASF security to get all CVEs allocated by Google to Apache > Commons components transferred to the ASF (we can edit them once we have > ownership) > 6. Ask the ASF security team to contact Google to make sure that Google > follows the CNA rules and stops allocating CVEs for projects outside of > its scope. > > If there is agreement to this approach, I'll volunteer to get the things > on the list above done. Depending on the number of issues, I may be > asking for help with 4. > > Given this is all public, I don't see any need to use the security@c.a.o > list unless we come across a valid, non-public issue. > > Mark > > > > On 11/10/2022 00:29, Roman Wagner wrote: > > Hi Bruno, hi Eric, > > > > I think we've just missed the discussion that you want to get > notifications > > about Bug reports for all apache-commons projects integrated in oss-fuzz. > > For that reason, we have tried to reach to the projects maintainers via > > public issues for every new project during the onboarding. Since we are > not > > focusing only on apache commons software we are not familiar with your > > internal process, however we are flexible to adopt. We are very > interested > > in any collaboration with maintainers if we are able to reach them. From > > your discussion I suggest that we first of all give you access to all > those > > projects and later on merge those different oss-fuzz projects into one > > project. Which email addresses should we add? In appache-commons there > are > > the following four: > > > > - fuzz-test...@commons.apache.org > > - brunodepau...@gmail.com > > - peteralfred...@gmail.com > > - boa...@gmail.com > > > > Should I add all of them? Should I add any additional mail address? > > > > Best regards > > Roman > > > > On Tue, Oct 11, 2022 at 12:13 AM Bruno Kinoshita > wrote: > > > >> Hi Matt, > >> > >> I don't think this fuzz project should be making any of these issues > >>> public unless they plan to donate some developers to fix the issues, > >>> too. This is an ASF project, not some Google-sponsored OSS project > >>> staffed with Google employees. > >>> > >> > >> I agree. This was the reason for the apache-commons project with a > >> different policy. > >> > >> In my opinion, the issue here is a company that profits from security > >> testing services/software-as-service setting up oss-fuzz to send > >> notifications to their internal team. Even though they say they tried to > >> communicate with us, a delay in having a response should not mean they > must > >> make it public anyway. > >> > >> It would be fine (again, IMO) to bring those Commons components under > the > >> apache-commons oss-fuzz project, and remove the existing projects that > do > >> not notify anyone from the ASF. That way we would receive notifications > and > >> could take some action to fix it. > >> > >> Bruno > >> > >> On Tue, 11 Oct 2022 at 10:57, Matt Sicker wrote: > >> > >>> I don't think this fuzz project should be making any of these issues > >>> public unless they plan to donate some developers to fix the issues, > >>> too. This is an ASF project, not some Google-sponsored OSS project > >>> staffed with Google employees. > >>> > >>> On Mon, Oct 10, 2022 at 4:41 PM Bruno Kinoshita > >> wrote: > > The JIRA issue linked appears to be one of those reported based on the > existing CVE's that were generated for jxpath. > > I opened the CVE, and the link is to an oss-fuzz bug indeed: > https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47133 > > If you look at the left side bar, there is a list of people notified > of > this issue. It should match what's in the project.yaml file I lin
[jxpath] reported CVE and path forward
Howdy folks, I recently saw that there was a reported CVE[1] for Apache JXPath that became public due to no response to the reporter over 90 days. I am uncertain if the reporter had tried reaching out to the appropriate security lists before-hand and was ignored, or failed to follow our established procedures. Regardless, the issue is now public. I have not personally verified the vulnerability, nor assessed the impact. NIST thinks it is a Big Deal, though, scoring it 9.8/10 [2] It is hard to assess impact since the project does not publish artifacts to maven central, but I'm also taking that as an indicator of low adoption at this point in time. Further, the project has not had a release since 2015. There has been very limited mailing list activity, and the last 5 years of commits have only been typo/comment fixes. If there is no community around it, is there a path to retirement? What are the next steps? Thanks, Mike [1]: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47133 [2]: https://nvd.nist.gov/vuln/detail/CVE-2022-41852 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
