Re: [all] OSS Fuzz
A quick update: OSS-Fuzz has gained coverage support for Java. You can access the latest apache-commons report at https://oss-fuzz.com/coverage-report/job/libfuzzer_asan_apache-commons/latest and check how well the fuzzer is doing. Fabian On Thu, Apr 22, 2021, 17:44 Fabian Meumertzheim < meumertzh...@code-intelligence.com> wrote: > On Thu, Apr 22, 2021 at 5:27 PM Peter Lee wrote: > > > I just created a PR in Compress > > https://github.com/apache/commons-compress/pull/189 > > Thanks! > > > IIUC I could create a PR github.com/google/oss-fuzz to include my > google account in auto_ccs, and I should ask the primary contact, who is > Stefen, to sign off my PR. Am I right about this? > > Precisely, just mention @bodewig in the PR description. There is no > formalized procedure, but this should work. > > Best, > Fabian >
Re: [all] OSS-Fuzz Issue Publication
No worries, I'm also not in a rush to change anything, so we can give this discussion the space and time it deserves. If you want me to weigh in on any issue you open on GitHub, just @fmeum. An additional argument in favor of a delayed publication could be that sometimes completely unrelated upstream changes end up "fixing" a security issue: The original testcase triggering that issue in OSS-Fuzz no longer does so. But since the root cause hasn't been fixed, letting the fuzzer run for a couple of minutes with the now public testcase will reproduce the original security issue. Of course, someone who goes to those lengths could just run the fuzzers themselves, so the actual impact of that situation is not clear. On Sun, May 9, 2021 at 8:54 PM Stefan Bodewig wrote: > Many thanks Fabian > > and sorry for the delay - unfortunately I'm not really able to free up > as much time as necessary for any OSS stuff right now > > On 2021-05-03, Fabian Meumertzheim wrote: > > > The behavior you are observing has only become the standard somewhat > > recently [1], which is also why I had decided to point it out before we > > performed the integration [2]. > > > [1] https://github.com/google/oss-fuzz/issues/5255 > > I must have overlooked that back then - or just didn't understand what > it meant. One key is the phrase "after a patch is released" which also > is used in [1] which means a completely different thing to ASF > communities than to the person opening the issue above. Nobody around > here would argue against disclosing details of a vulnerability after a > new release containing the fix is available. > > The best we can do probably is pointing out that the new policy is > incompatible with the ASF security policy - point 14 in > > https://www.apache.org/security/committers.html#vulnerability-handling > > without trying to argue who is right. Going from there we will see > whether there is an option for ASF projects to continue using OSS Fuzz > or not. Unfortunately I believe this discussion must be driven by > somebody with a predictable and sufficiently large slice of time for > this, which I will not be for at least the next week, likely longer. > > Unless anybody else jumps in I'll take it on myself once I believe to be > available. Fortunately so far no issues have shown up that would force > ou hand - and even if something came up I'm sure we could figure out > some sort of singular exemption. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [all] OSS-Fuzz Issue Publication
Many thanks Fabian and sorry for the delay - unfortunately I'm not really able to free up as much time as necessary for any OSS stuff right now On 2021-05-03, Fabian Meumertzheim wrote: > The behavior you are observing has only become the standard somewhat > recently [1], which is also why I had decided to point it out before we > performed the integration [2]. > [1] https://github.com/google/oss-fuzz/issues/5255 I must have overlooked that back then - or just didn't understand what it meant. One key is the phrase "after a patch is released" which also is used in [1] which means a completely different thing to ASF communities than to the person opening the issue above. Nobody around here would argue against disclosing details of a vulnerability after a new release containing the fix is available. The best we can do probably is pointing out that the new policy is incompatible with the ASF security policy - point 14 in https://www.apache.org/security/committers.html#vulnerability-handling without trying to argue who is right. Going from there we will see whether there is an option for ASF projects to continue using OSS Fuzz or not. Unfortunately I believe this discussion must be driven by somebody with a predictable and sufficiently large slice of time for this, which I will not be for at least the next week, likely longer. Unless anybody else jumps in I'll take it on myself once I believe to be available. Fortunately so far no issues have shown up that would force ou hand - and even if something came up I'm sure we could figure out some sort of singular exemption. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS-Fuzz Issue Publication
Hi, The behavior you are observing has only become the standard somewhat recently [1], which is also why I had decided to point it out before we performed the integration [2]. Let me first confirm the facts: It is correct that OSS-Fuzz will automatically open the Monorail bugs to the public roughly a day after a patch has been verified upstream. The bug includes the crashing input, a truncated stack trace and all discussions that have been submitted on it. The detailed OSS-Fuzz report, including the full stack trace and minimized crashing input becomes semi-public: it can be accessed by anyone who is a primary_contact/auto_cc for *any* project hosted on OSS-Fuzz. The rationale for the new policy is explained briefly in [1]. Based on a conversation I had with an OSS-Fuzz maintainer, I would paraphrase this as follows: An upstream patch, no matter how innocuous the commit message may be, always has the potential to give away the fact that it exists to fix a security issue. This is especially true if a malicious third party has any interest in finding security issues in a particular open-source project. However, the easiest and certainly most cost-effective way to find such issues would not be to monitor and audit upstream patches, but rather to dedicate more CPU time to running the project's own fuzzers than OSS-Fuzz. While running OSS-Fuzz for all projects is certainly costing Google a lot of money, outperforming them on a single project is not expensive. Hence, bugs found by OSS-Fuzz should be assumed to be already known to anybody with a particular interest in breaking a particular library. Since test cases produced by OSS-Fuzz are not complete exploits (they are inputs to libraries, not applications), they aren't going to be useful for "drive-by script kiddies" or the likes. From that point of view, where dedicated third parties already have the opportunity to find bugs before the maintainers, this becomes more about keeping the user base in the know about security issues in the libraries they are using, e.g. via a project like OSV [3] as mentioned in [1]. That said, I fully understand your concerns and think that it might be possible to accommodate both your usual patch release workflow as well as the general OSS-Fuzz policies. For example, it could be reasonable to keep the crashing inputs non-public for an extended period of time (e.g. the 30 days bugs originally remained private for after the fix), while the conceptual information about the bug (i.e., it's Monorail entry on [4]) becomes public immediately. Can you think of a "middle ground" like this that would work for Apache? Given that OSS-Fuzz has very responsive maintainers and is fundamentally open-source, I would suggest to open an issue on the repository where follow-up discussions are accessible to a wider audience. It may be the case that the change made in [1] has not received the publicity it deserves yet and I'm sure the OSS-Fuzz maintainers would welcome your feedback on the new policy. If you prefer it this way, I could also create the issue myself tomorrow. Fabian [1] https://github.com/google/oss-fuzz/issues/5255 [2] https://mail-archives.apache.org/mod_mbox/commons-dev/202104.mbox/%3CCAMD8YMQ3ODf%3DTn8YAjsUkmym2wZ3TogR8uMy%2Bhb82asL6YEQhQ%40mail.gmail.com%3E [3] https://github.com/google/osv [4] https://bugs.chromium.org/p/oss-fuzz/issues/list On Mon, May 3, 2021 at 2:59 PM Stefan Bodewig wrote: > Hi (Fabian) > > by now we've resolved the first issues detected by ClusterFuzz (and I > forgot to credit it OSS Fuzz in Compress, my bad). What we observed is > that the issues became public automatically once the patch fixing the > issue was merged into master and ClusterFuzz reran the test. In the case > of Compress somewhere around 24 hours after fixing things in master. > > So far none of the issues we resolved would be deemed as a security > issue. But now we wonder, what if something indeed was a security issue > that we do not want to become public knowledge before we have cut a > release? Is there a way to prevent a verified and fixed issue from > becoming public automatically? > > Here at the ASF we vote on releases, and we vote on the code base in our > default branch (master for most if not all components). Voting takes at > least three days, so the current behavior would mean the issue became > public knowledge a few days before a release fixing it was available. > > Can you shed any light on this? > > Thanks > > Stefan >
Re: [all] OSS-Fuzz Issue Publication
Voting takes three days or less if we decide we need an emergency release for a security issue for example. In reality, it can take weeks for a release manager to volunteer for a given component, review code, PRs, Jiras, an so on, before going through all the hoops to create a release candidate and then the release. So, the buffer of time should never be automatic. The issue should be made public only after a release in the case of security issues. Gary On Mon, May 3, 2021, 08:59 Stefan Bodewig wrote: > Hi (Fabian) > > by now we've resolved the first issues detected by ClusterFuzz (and I > forgot to credit it OSS Fuzz in Compress, my bad). What we observed is > that the issues became public automatically once the patch fixing the > issue was merged into master and ClusterFuzz reran the test. In the case > of Compress somewhere around 24 hours after fixing things in master. > > So far none of the issues we resolved would be deemed as a security > issue. But now we wonder, what if something indeed was a security issue > that we do not want to become public knowledge before we have cut a > release? Is there a way to prevent a verified and fixed issue from > becoming public automatically? > > Here at the ASF we vote on releases, and we vote on the code base in our > default branch (master for most if not all components). Voting takes at > least three days, so the current behavior would mean the issue became > public knowledge a few days before a release fixing it was available. > > Can you shed any light on this? > > Thanks > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [all] OSS Fuzz
On Thu, Apr 22, 2021 at 5:27 PM Peter Lee wrote: > I just created a PR in Compress > https://github.com/apache/commons-compress/pull/189 Thanks! > IIUC I could create a PR github.com/google/oss-fuzz to include my google > account in auto_ccs, and I should ask the primary contact, who is Stefen, to > sign off my PR. Am I right about this? Precisely, just mention @bodewig in the PR description. There is no formalized procedure, but this should work. Best, Fabian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
Hi Fabian, Thanks a lot for all this. > One more thing: Could you perhaps add the following line to the READMEs of > compress and imaging? > I just created a PR in Compress https://github.com/apache/commons-compress/pull/189 Seems I missed a lot these days. :-( I also got a Google account(peteralfredlee at gmail.com). IIUC I could create a PR github.com/google/oss-fuzz to include my google account in auto_ccs, and I should ask the primary contact, who is Stefen, to sign off my PR. Am I right about this? cheers, Lee On 4 20 2021, at 10:27 , Fabian Meumertzheim wrote: > The first OSS-Fuzz build passed and some bugs have already been created. > Everything looks good from my side, but let me know if you have any > questions. > > One more thing: Could you perhaps add the following line to the READMEs of > compress and imaging? > > [](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened=1=proj:apache-commons > ) > > This will give you both an indicator of the fuzzer build status as well as > a convenient link to the bugs on the OSS-Fuzz issue tracker. > > On Mon, Apr 19, 2021, 12:16 sebb wrote: > > On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig wrote: > > > > > > On 2021-04-18, Stefan Bodewig wrote: > > > > > > > I've created https://issues.apache.org/jira/browse/INFRA-21741 if you > > > > want to lend a hand moderating, you may want to add yourself to the > > > > ticket before the list is created. > > > > > > The list has been created, so if you want to receive the fuzz reports > > > please subscribe to fuzz-testing@commons and one of the intial > > > moderators will accept the subscription (if we can recognize the email > > > address :-). > > > > Best to ensure that you use an address that is listed in your LDAP account. > > Visit https://whimsy.apache.org/roster/committer/__self__ to maintain the > > list. > > Moderators can then use Whimsy to search committers by email address > > to find you. > > > > Also, it looks like the content will appear on lists.a.o (requires > > login to view): > > https://lists.apache.org/list.html?fuzz-test...@commons.apache.org > > > > There's nothing there at present, so the URL will report an error > > > Stefan > > > > > > - > > > 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: [all] OSS Fuzz
Done in imaging! Thanks https://github.com/apache/commons-imaging/pull/130 Bruno On Wednesday, 21 April 2021, 2:27:38 am NZST, Fabian Meumertzheim wrote: The first OSS-Fuzz build passed and some bugs have already been created. Everything looks good from my side, but let me know if you have any questions. One more thing: Could you perhaps add the following line to the READMEs of compress and imaging? [](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened=1=proj:apache-commons ) This will give you both an indicator of the fuzzer build status as well as a convenient link to the bugs on the OSS-Fuzz issue tracker. On Mon, Apr 19, 2021, 12:16 sebb wrote: > On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig wrote: > > > > On 2021-04-18, Stefan Bodewig wrote: > > > > > I've created https://issues.apache.org/jira/browse/INFRA-21741 if you > > > want to lend a hand moderating, you may want to add yourself to the > > > ticket before the list is created. > > > > The list has been created, so if you want to receive the fuzz reports > > please subscribe to fuzz-testing@commons and one of the intial > > moderators will accept the subscription (if we can recognize the email > > address :-). > > Best to ensure that you use an address that is listed in your LDAP account. > Visit https://whimsy.apache.org/roster/committer/__self__ to maintain the > list. > Moderators can then use Whimsy to search committers by email address > to find you. > > Also, it looks like the content will appear on lists.a.o (requires > login to view): > https://lists.apache.org/list.html?fuzz-test...@commons.apache.org > > There's nothing there at present, so the URL will report an error > > Stefan > > > > - > > 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: [all] OSS Fuzz
I see that now. Thanks for handling the ticket! On Tue, 20 Apr 2021 at 11:38, sebb wrote: > > On Tue, 20 Apr 2021 at 17:22, Matt Sicker wrote: > > > > I've tried adding that email to the allow-subscribe list for that > > mailing list. Let's see if the next messages get through without > > moderation now. > > As already noted, the Return-Path is different for each email - have a > look at the headers in the email source. > > I have raised INFRA-21752 with a potential solution. > > > On Tue, 20 Apr 2021 at 10:46, Matt Sicker wrote: > > > > > > I've accepted all the moderation requests so far, though I also get > > > CC'd on the same emails, so my inbox is a little messy at the moment > > > to verify that it's going through the mailing list, too. There's > > > already been like 20 alerts found, so good call on the separate > > > mailing list! :) > > > > > > On Tue, 20 Apr 2021 at 10:43, sebb wrote: > > > > > > > > On Tue, 20 Apr 2021 at 16:34, Fabian Meumertzheim > > > > wrote: > > > > > > > > > > I think that the sender address has been > > > > > monorail+v2.382749...@chromium.org for > > > > > me since February, so it might be more stable than it looks. > > > > > > > > Yes, but ezmlm uses the envelope sender, i.e. the Return-Path. > > > > > > > > At least the current ones all have the same domain name. > > > > > > > > If this is sufficiently unique it should be possible to filter all > > > > such emails without opening the floodgates. > > > > (the filter just removes the variable part, so normal moderation rules > > > > can be applied) > > > > > > > > > On Tue, Apr 20, 2021, 17:30 Matt Sicker wrote: > > > > > > > > > > > Guess we'll have to ask infra then. They probably have a way to > > > > > > filter > > > > > > based on regex or something. > > > > > > > > > > > > On Tue, 20 Apr 2021 at 10:05, sebb wrote: > > > > > > > > > > > > > > On Tue, 20 Apr 2021 at 15:53, Matt Sicker > > > > > > > wrote: > > > > > > > > > > > > > > > Looks like we need to add the bot email as an allowed sender to > > > > > > > > the > > > > > > list. > > > > > > > > > > > > > > > > > > > > > > Easier said than done, as email appears to use a dynamic address. > > > > > > > > > > > > > > > > > > > > > > Otherwise, I’ve seen the alerts start already > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 20, 2021 at 09:27 Fabian Meumertzheim < > > > > > > > > meumertzh...@code-intelligence.com> wrote: > > > > > > > > > > > > > > > > > The first OSS-Fuzz build passed and some bugs have already > > > > > > > > > been > > > > > > created. > > > > > > > > > Everything looks good from my side, but let me know if you > > > > > > > > > have any > > > > > > > > > questions. > > > > > > > > > > > > > > > > > > One more thing: Could you perhaps add the following line to > > > > > > > > > the > > > > > > READMEs > > > > > > > > of > > > > > > > > > compress and imaging? > > > > > > > > > > > > > > > > > > [](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened=1=proj:apache-commons > > > > > > > > > ) > > > > > > > > > > > > > > > > > > This will give you both an indicator of the fuzzer build > > > > > > > > > status as > > > > > > well > > > > > > > > as > > > > > > > > > a convenient link to the bugs on the OSS-Fuzz issue tracker. > > > > > > > > > > > > > > > > > > On Mon, Apr 19, 2021, 12:16 sebb wrote: > > > > > > > > > > > > > > > > > > > On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On 2021-04-18, Stefan Bodewig wrote: > > > > > > > > > > > > > > > > > > > > > > > I've created > > > > > > > > > > > > https://issues.apache.org/jira/browse/INFRA-21741 > > > > > > if > > > > > > > > > you > > > > > > > > > > > > want to lend a hand moderating, you may want to add > > > > > > > > > > > > yourself > > > > > > to the > > > > > > > > > > > > ticket before the list is created. > > > > > > > > > > > > > > > > > > > > > > The list has been created, so if you want to receive the > > > > > > > > > > > fuzz > > > > > > reports > > > > > > > > > > > please subscribe to fuzz-testing@commons and one of the > > > > > > > > > > > intial > > > > > > > > > > > moderators will accept the subscription (if we can > > > > > > > > > > > recognize the > > > > > > > > email > > > > > > > > > > > address :-). > > > > > > > > > > > > > > > > > > > > Best to ensure that you use an address that is listed in > > > > > > > > > > your LDAP > > > > > > > > > account. > > > > > > > > > > Visit https://whimsy.apache.org/roster/committer/__self__ to > > > > > > maintain > > > > > > > > > the > > > > > > > > > > list. > > > > > > > > > > Moderators can then use Whimsy to search committers by email > > > > > > address > > > > > > > > > > to find you. > > > > > > > > > > > > > > > > > >
Re: [all] OSS Fuzz
On Tue, 20 Apr 2021 at 17:22, Matt Sicker wrote: > > I've tried adding that email to the allow-subscribe list for that > mailing list. Let's see if the next messages get through without > moderation now. As already noted, the Return-Path is different for each email - have a look at the headers in the email source. I have raised INFRA-21752 with a potential solution. > On Tue, 20 Apr 2021 at 10:46, Matt Sicker wrote: > > > > I've accepted all the moderation requests so far, though I also get > > CC'd on the same emails, so my inbox is a little messy at the moment > > to verify that it's going through the mailing list, too. There's > > already been like 20 alerts found, so good call on the separate > > mailing list! :) > > > > On Tue, 20 Apr 2021 at 10:43, sebb wrote: > > > > > > On Tue, 20 Apr 2021 at 16:34, Fabian Meumertzheim > > > wrote: > > > > > > > > I think that the sender address has been > > > > monorail+v2.382749...@chromium.org for > > > > me since February, so it might be more stable than it looks. > > > > > > Yes, but ezmlm uses the envelope sender, i.e. the Return-Path. > > > > > > At least the current ones all have the same domain name. > > > > > > If this is sufficiently unique it should be possible to filter all > > > such emails without opening the floodgates. > > > (the filter just removes the variable part, so normal moderation rules > > > can be applied) > > > > > > > On Tue, Apr 20, 2021, 17:30 Matt Sicker wrote: > > > > > > > > > Guess we'll have to ask infra then. They probably have a way to filter > > > > > based on regex or something. > > > > > > > > > > On Tue, 20 Apr 2021 at 10:05, sebb wrote: > > > > > > > > > > > > On Tue, 20 Apr 2021 at 15:53, Matt Sicker wrote: > > > > > > > > > > > > > Looks like we need to add the bot email as an allowed sender to > > > > > > > the > > > > > list. > > > > > > > > > > > > > > > > > > > Easier said than done, as email appears to use a dynamic address. > > > > > > > > > > > > > > > > > > > Otherwise, I’ve seen the alerts start already > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 20, 2021 at 09:27 Fabian Meumertzheim < > > > > > > > meumertzh...@code-intelligence.com> wrote: > > > > > > > > > > > > > > > The first OSS-Fuzz build passed and some bugs have already been > > > > > created. > > > > > > > > Everything looks good from my side, but let me know if you have > > > > > > > > any > > > > > > > > questions. > > > > > > > > > > > > > > > > One more thing: Could you perhaps add the following line to the > > > > > READMEs > > > > > > > of > > > > > > > > compress and imaging? > > > > > > > > > > > > > > > > [](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened=1=proj:apache-commons > > > > > > > > ) > > > > > > > > > > > > > > > > This will give you both an indicator of the fuzzer build status > > > > > > > > as > > > > > well > > > > > > > as > > > > > > > > a convenient link to the bugs on the OSS-Fuzz issue tracker. > > > > > > > > > > > > > > > > On Mon, Apr 19, 2021, 12:16 sebb wrote: > > > > > > > > > > > > > > > > > On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On 2021-04-18, Stefan Bodewig wrote: > > > > > > > > > > > > > > > > > > > > > I've created > > > > > > > > > > > https://issues.apache.org/jira/browse/INFRA-21741 > > > > > if > > > > > > > > you > > > > > > > > > > > want to lend a hand moderating, you may want to add > > > > > > > > > > > yourself > > > > > to the > > > > > > > > > > > ticket before the list is created. > > > > > > > > > > > > > > > > > > > > The list has been created, so if you want to receive the > > > > > > > > > > fuzz > > > > > reports > > > > > > > > > > please subscribe to fuzz-testing@commons and one of the > > > > > > > > > > intial > > > > > > > > > > moderators will accept the subscription (if we can > > > > > > > > > > recognize the > > > > > > > email > > > > > > > > > > address :-). > > > > > > > > > > > > > > > > > > Best to ensure that you use an address that is listed in your > > > > > > > > > LDAP > > > > > > > > account. > > > > > > > > > Visit https://whimsy.apache.org/roster/committer/__self__ to > > > > > maintain > > > > > > > > the > > > > > > > > > list. > > > > > > > > > Moderators can then use Whimsy to search committers by email > > > > > address > > > > > > > > > to find you. > > > > > > > > > > > > > > > > > > Also, it looks like the content will appear on lists.a.o > > > > > > > > > (requires > > > > > > > > > login to view): > > > > > > > > > https://lists.apache.org/list.html?fuzz-test...@commons.apache.org > > > > > > > > > > > > > > > > > > There's nothing there at present, so the URL will report an > > > > > > > > > error > > > > > > > > > > Stefan > > > > > > > > > > > > > > > > > > > > > > > >
Re: [all] OSS Fuzz
I've tried adding that email to the allow-subscribe list for that mailing list. Let's see if the next messages get through without moderation now. On Tue, 20 Apr 2021 at 10:46, Matt Sicker wrote: > > I've accepted all the moderation requests so far, though I also get > CC'd on the same emails, so my inbox is a little messy at the moment > to verify that it's going through the mailing list, too. There's > already been like 20 alerts found, so good call on the separate > mailing list! :) > > On Tue, 20 Apr 2021 at 10:43, sebb wrote: > > > > On Tue, 20 Apr 2021 at 16:34, Fabian Meumertzheim > > wrote: > > > > > > I think that the sender address has been > > > monorail+v2.382749...@chromium.org for > > > me since February, so it might be more stable than it looks. > > > > Yes, but ezmlm uses the envelope sender, i.e. the Return-Path. > > > > At least the current ones all have the same domain name. > > > > If this is sufficiently unique it should be possible to filter all > > such emails without opening the floodgates. > > (the filter just removes the variable part, so normal moderation rules > > can be applied) > > > > > On Tue, Apr 20, 2021, 17:30 Matt Sicker wrote: > > > > > > > Guess we'll have to ask infra then. They probably have a way to filter > > > > based on regex or something. > > > > > > > > On Tue, 20 Apr 2021 at 10:05, sebb wrote: > > > > > > > > > > On Tue, 20 Apr 2021 at 15:53, Matt Sicker wrote: > > > > > > > > > > > Looks like we need to add the bot email as an allowed sender to the > > > > list. > > > > > > > > > > > > > > > > Easier said than done, as email appears to use a dynamic address. > > > > > > > > > > > > > > > > Otherwise, I’ve seen the alerts start already > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 20, 2021 at 09:27 Fabian Meumertzheim < > > > > > > meumertzh...@code-intelligence.com> wrote: > > > > > > > > > > > > > The first OSS-Fuzz build passed and some bugs have already been > > > > created. > > > > > > > Everything looks good from my side, but let me know if you have > > > > > > > any > > > > > > > questions. > > > > > > > > > > > > > > One more thing: Could you perhaps add the following line to the > > > > READMEs > > > > > > of > > > > > > > compress and imaging? > > > > > > > > > > > > > > [](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened=1=proj:apache-commons > > > > > > > ) > > > > > > > > > > > > > > This will give you both an indicator of the fuzzer build status as > > > > well > > > > > > as > > > > > > > a convenient link to the bugs on the OSS-Fuzz issue tracker. > > > > > > > > > > > > > > On Mon, Apr 19, 2021, 12:16 sebb wrote: > > > > > > > > > > > > > > > On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On 2021-04-18, Stefan Bodewig wrote: > > > > > > > > > > > > > > > > > > > I've created > > > > > > > > > > https://issues.apache.org/jira/browse/INFRA-21741 > > > > if > > > > > > > you > > > > > > > > > > want to lend a hand moderating, you may want to add yourself > > > > to the > > > > > > > > > > ticket before the list is created. > > > > > > > > > > > > > > > > > > The list has been created, so if you want to receive the fuzz > > > > reports > > > > > > > > > please subscribe to fuzz-testing@commons and one of the intial > > > > > > > > > moderators will accept the subscription (if we can recognize > > > > > > > > > the > > > > > > email > > > > > > > > > address :-). > > > > > > > > > > > > > > > > Best to ensure that you use an address that is listed in your > > > > > > > > LDAP > > > > > > > account. > > > > > > > > Visit https://whimsy.apache.org/roster/committer/__self__ to > > > > maintain > > > > > > > the > > > > > > > > list. > > > > > > > > Moderators can then use Whimsy to search committers by email > > > > address > > > > > > > > to find you. > > > > > > > > > > > > > > > > Also, it looks like the content will appear on lists.a.o > > > > > > > > (requires > > > > > > > > login to view): > > > > > > > > https://lists.apache.org/list.html?fuzz-test...@commons.apache.org > > > > > > > > > > > > > > > > There's nothing there at present, so the URL will report an > > > > > > > > error > > > > > > > > > Stefan > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > 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: [all] OSS Fuzz
I've accepted all the moderation requests so far, though I also get CC'd on the same emails, so my inbox is a little messy at the moment to verify that it's going through the mailing list, too. There's already been like 20 alerts found, so good call on the separate mailing list! :) On Tue, 20 Apr 2021 at 10:43, sebb wrote: > > On Tue, 20 Apr 2021 at 16:34, Fabian Meumertzheim > wrote: > > > > I think that the sender address has been monorail+v2.382749...@chromium.org > > for > > me since February, so it might be more stable than it looks. > > Yes, but ezmlm uses the envelope sender, i.e. the Return-Path. > > At least the current ones all have the same domain name. > > If this is sufficiently unique it should be possible to filter all > such emails without opening the floodgates. > (the filter just removes the variable part, so normal moderation rules > can be applied) > > > On Tue, Apr 20, 2021, 17:30 Matt Sicker wrote: > > > > > Guess we'll have to ask infra then. They probably have a way to filter > > > based on regex or something. > > > > > > On Tue, 20 Apr 2021 at 10:05, sebb wrote: > > > > > > > > On Tue, 20 Apr 2021 at 15:53, Matt Sicker wrote: > > > > > > > > > Looks like we need to add the bot email as an allowed sender to the > > > list. > > > > > > > > > > > > > Easier said than done, as email appears to use a dynamic address. > > > > > > > > > > > > > Otherwise, I’ve seen the alerts start already > > > > > > > > > > > > > > > > > > On Tue, Apr 20, 2021 at 09:27 Fabian Meumertzheim < > > > > > meumertzh...@code-intelligence.com> wrote: > > > > > > > > > > > The first OSS-Fuzz build passed and some bugs have already been > > > created. > > > > > > Everything looks good from my side, but let me know if you have any > > > > > > questions. > > > > > > > > > > > > One more thing: Could you perhaps add the following line to the > > > READMEs > > > > > of > > > > > > compress and imaging? > > > > > > > > > > > > [](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened=1=proj:apache-commons > > > > > > ) > > > > > > > > > > > > This will give you both an indicator of the fuzzer build status as > > > well > > > > > as > > > > > > a convenient link to the bugs on the OSS-Fuzz issue tracker. > > > > > > > > > > > > On Mon, Apr 19, 2021, 12:16 sebb wrote: > > > > > > > > > > > > > On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig > > > > > wrote: > > > > > > > > > > > > > > > > On 2021-04-18, Stefan Bodewig wrote: > > > > > > > > > > > > > > > > > I've created https://issues.apache.org/jira/browse/INFRA-21741 > > > if > > > > > > you > > > > > > > > > want to lend a hand moderating, you may want to add yourself > > > to the > > > > > > > > > ticket before the list is created. > > > > > > > > > > > > > > > > The list has been created, so if you want to receive the fuzz > > > reports > > > > > > > > please subscribe to fuzz-testing@commons and one of the intial > > > > > > > > moderators will accept the subscription (if we can recognize the > > > > > email > > > > > > > > address :-). > > > > > > > > > > > > > > Best to ensure that you use an address that is listed in your LDAP > > > > > > account. > > > > > > > Visit https://whimsy.apache.org/roster/committer/__self__ to > > > maintain > > > > > > the > > > > > > > list. > > > > > > > Moderators can then use Whimsy to search committers by email > > > address > > > > > > > to find you. > > > > > > > > > > > > > > Also, it looks like the content will appear on lists.a.o (requires > > > > > > > login to view): > > > > > > > https://lists.apache.org/list.html?fuzz-test...@commons.apache.org > > > > > > > > > > > > > > There's nothing there at present, so the URL will report an error > > > > > > > > Stefan > > > > > > > > > > > > > > > > > > > - > > > > > > > > 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 > > > > > > > > - > 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
Re: [all] OSS Fuzz
On Tue, 20 Apr 2021 at 16:34, Fabian Meumertzheim wrote: > > I think that the sender address has been monorail+v2.382749...@chromium.org > for > me since February, so it might be more stable than it looks. Yes, but ezmlm uses the envelope sender, i.e. the Return-Path. At least the current ones all have the same domain name. If this is sufficiently unique it should be possible to filter all such emails without opening the floodgates. (the filter just removes the variable part, so normal moderation rules can be applied) > On Tue, Apr 20, 2021, 17:30 Matt Sicker wrote: > > > Guess we'll have to ask infra then. They probably have a way to filter > > based on regex or something. > > > > On Tue, 20 Apr 2021 at 10:05, sebb wrote: > > > > > > On Tue, 20 Apr 2021 at 15:53, Matt Sicker wrote: > > > > > > > Looks like we need to add the bot email as an allowed sender to the > > list. > > > > > > > > > > Easier said than done, as email appears to use a dynamic address. > > > > > > > > > > Otherwise, I’ve seen the alerts start already > > > > > > > > > > > > > > On Tue, Apr 20, 2021 at 09:27 Fabian Meumertzheim < > > > > meumertzh...@code-intelligence.com> wrote: > > > > > > > > > The first OSS-Fuzz build passed and some bugs have already been > > created. > > > > > Everything looks good from my side, but let me know if you have any > > > > > questions. > > > > > > > > > > One more thing: Could you perhaps add the following line to the > > READMEs > > > > of > > > > > compress and imaging? > > > > > > > > > > [](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened=1=proj:apache-commons > > > > > ) > > > > > > > > > > This will give you both an indicator of the fuzzer build status as > > well > > > > as > > > > > a convenient link to the bugs on the OSS-Fuzz issue tracker. > > > > > > > > > > On Mon, Apr 19, 2021, 12:16 sebb wrote: > > > > > > > > > > > On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig > > > > wrote: > > > > > > > > > > > > > > On 2021-04-18, Stefan Bodewig wrote: > > > > > > > > > > > > > > > I've created https://issues.apache.org/jira/browse/INFRA-21741 > > if > > > > > you > > > > > > > > want to lend a hand moderating, you may want to add yourself > > to the > > > > > > > > ticket before the list is created. > > > > > > > > > > > > > > The list has been created, so if you want to receive the fuzz > > reports > > > > > > > please subscribe to fuzz-testing@commons and one of the intial > > > > > > > moderators will accept the subscription (if we can recognize the > > > > email > > > > > > > address :-). > > > > > > > > > > > > Best to ensure that you use an address that is listed in your LDAP > > > > > account. > > > > > > Visit https://whimsy.apache.org/roster/committer/__self__ to > > maintain > > > > > the > > > > > > list. > > > > > > Moderators can then use Whimsy to search committers by email > > address > > > > > > to find you. > > > > > > > > > > > > Also, it looks like the content will appear on lists.a.o (requires > > > > > > login to view): > > > > > > https://lists.apache.org/list.html?fuzz-test...@commons.apache.org > > > > > > > > > > > > There's nothing there at present, so the URL will report an error > > > > > > > Stefan > > > > > > > > > > > > > > > > - > > > > > > > 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 > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
On Tue, 20 Apr 2021 at 16:30, Matt Sicker wrote: > > Guess we'll have to ask infra then. They probably have a way to filter > based on regex or something. I just remembered we had to do something similar for Travis and Twitter, see INFRA-18843 and INFRA-19360 Are you going to accept the moderation requests for now? > On Tue, 20 Apr 2021 at 10:05, sebb wrote: > > > > On Tue, 20 Apr 2021 at 15:53, Matt Sicker wrote: > > > > > Looks like we need to add the bot email as an allowed sender to the list. > > > > > > > Easier said than done, as email appears to use a dynamic address. > > > > > > > Otherwise, I’ve seen the alerts start already > > > > > > > > > > On Tue, Apr 20, 2021 at 09:27 Fabian Meumertzheim < > > > meumertzh...@code-intelligence.com> wrote: > > > > > > > The first OSS-Fuzz build passed and some bugs have already been created. > > > > Everything looks good from my side, but let me know if you have any > > > > questions. > > > > > > > > One more thing: Could you perhaps add the following line to the READMEs > > > of > > > > compress and imaging? > > > > > > > > [](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened=1=proj:apache-commons > > > > ) > > > > > > > > This will give you both an indicator of the fuzzer build status as well > > > as > > > > a convenient link to the bugs on the OSS-Fuzz issue tracker. > > > > > > > > On Mon, Apr 19, 2021, 12:16 sebb wrote: > > > > > > > > > On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig > > > wrote: > > > > > > > > > > > > On 2021-04-18, Stefan Bodewig wrote: > > > > > > > > > > > > > I've created https://issues.apache.org/jira/browse/INFRA-21741 if > > > > you > > > > > > > want to lend a hand moderating, you may want to add yourself to > > > > > > > the > > > > > > > ticket before the list is created. > > > > > > > > > > > > The list has been created, so if you want to receive the fuzz > > > > > > reports > > > > > > please subscribe to fuzz-testing@commons and one of the intial > > > > > > moderators will accept the subscription (if we can recognize the > > > email > > > > > > address :-). > > > > > > > > > > Best to ensure that you use an address that is listed in your LDAP > > > > account. > > > > > Visit https://whimsy.apache.org/roster/committer/__self__ to maintain > > > > the > > > > > list. > > > > > Moderators can then use Whimsy to search committers by email address > > > > > to find you. > > > > > > > > > > Also, it looks like the content will appear on lists.a.o (requires > > > > > login to view): > > > > > https://lists.apache.org/list.html?fuzz-test...@commons.apache.org > > > > > > > > > > There's nothing there at present, so the URL will report an error > > > > > > Stefan > > > > > > > > > > > > - > > > > > > 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 > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
I think that the sender address has been monorail+v2.382749...@chromium.org for me since February, so it might be more stable than it looks. On Tue, Apr 20, 2021, 17:30 Matt Sicker wrote: > Guess we'll have to ask infra then. They probably have a way to filter > based on regex or something. > > On Tue, 20 Apr 2021 at 10:05, sebb wrote: > > > > On Tue, 20 Apr 2021 at 15:53, Matt Sicker wrote: > > > > > Looks like we need to add the bot email as an allowed sender to the > list. > > > > > > > Easier said than done, as email appears to use a dynamic address. > > > > > > > Otherwise, I’ve seen the alerts start already > > > > > > > > > > On Tue, Apr 20, 2021 at 09:27 Fabian Meumertzheim < > > > meumertzh...@code-intelligence.com> wrote: > > > > > > > The first OSS-Fuzz build passed and some bugs have already been > created. > > > > Everything looks good from my side, but let me know if you have any > > > > questions. > > > > > > > > One more thing: Could you perhaps add the following line to the > READMEs > > > of > > > > compress and imaging? > > > > > > > > [](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened=1=proj:apache-commons > > > > ) > > > > > > > > This will give you both an indicator of the fuzzer build status as > well > > > as > > > > a convenient link to the bugs on the OSS-Fuzz issue tracker. > > > > > > > > On Mon, Apr 19, 2021, 12:16 sebb wrote: > > > > > > > > > On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig > > > wrote: > > > > > > > > > > > > On 2021-04-18, Stefan Bodewig wrote: > > > > > > > > > > > > > I've created https://issues.apache.org/jira/browse/INFRA-21741 > if > > > > you > > > > > > > want to lend a hand moderating, you may want to add yourself > to the > > > > > > > ticket before the list is created. > > > > > > > > > > > > The list has been created, so if you want to receive the fuzz > reports > > > > > > please subscribe to fuzz-testing@commons and one of the intial > > > > > > moderators will accept the subscription (if we can recognize the > > > email > > > > > > address :-). > > > > > > > > > > Best to ensure that you use an address that is listed in your LDAP > > > > account. > > > > > Visit https://whimsy.apache.org/roster/committer/__self__ to > maintain > > > > the > > > > > list. > > > > > Moderators can then use Whimsy to search committers by email > address > > > > > to find you. > > > > > > > > > > Also, it looks like the content will appear on lists.a.o (requires > > > > > login to view): > > > > > https://lists.apache.org/list.html?fuzz-test...@commons.apache.org > > > > > > > > > > There's nothing there at present, so the URL will report an error > > > > > > Stefan > > > > > > > > > > > > > - > > > > > > 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 > >
Re: [all] OSS Fuzz
Guess we'll have to ask infra then. They probably have a way to filter based on regex or something. On Tue, 20 Apr 2021 at 10:05, sebb wrote: > > On Tue, 20 Apr 2021 at 15:53, Matt Sicker wrote: > > > Looks like we need to add the bot email as an allowed sender to the list. > > > > Easier said than done, as email appears to use a dynamic address. > > > > Otherwise, I’ve seen the alerts start already > > > > > > On Tue, Apr 20, 2021 at 09:27 Fabian Meumertzheim < > > meumertzh...@code-intelligence.com> wrote: > > > > > The first OSS-Fuzz build passed and some bugs have already been created. > > > Everything looks good from my side, but let me know if you have any > > > questions. > > > > > > One more thing: Could you perhaps add the following line to the READMEs > > of > > > compress and imaging? > > > > > > [](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened=1=proj:apache-commons > > > ) > > > > > > This will give you both an indicator of the fuzzer build status as well > > as > > > a convenient link to the bugs on the OSS-Fuzz issue tracker. > > > > > > On Mon, Apr 19, 2021, 12:16 sebb wrote: > > > > > > > On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig > > wrote: > > > > > > > > > > On 2021-04-18, Stefan Bodewig wrote: > > > > > > > > > > > I've created https://issues.apache.org/jira/browse/INFRA-21741 if > > > you > > > > > > want to lend a hand moderating, you may want to add yourself to the > > > > > > ticket before the list is created. > > > > > > > > > > The list has been created, so if you want to receive the fuzz reports > > > > > please subscribe to fuzz-testing@commons and one of the intial > > > > > moderators will accept the subscription (if we can recognize the > > email > > > > > address :-). > > > > > > > > Best to ensure that you use an address that is listed in your LDAP > > > account. > > > > Visit https://whimsy.apache.org/roster/committer/__self__ to maintain > > > the > > > > list. > > > > Moderators can then use Whimsy to search committers by email address > > > > to find you. > > > > > > > > Also, it looks like the content will appear on lists.a.o (requires > > > > login to view): > > > > https://lists.apache.org/list.html?fuzz-test...@commons.apache.org > > > > > > > > There's nothing there at present, so the URL will report an error > > > > > Stefan > > > > > > > > > > - > > > > > 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
Re: [all] OSS Fuzz
On Tue, 20 Apr 2021 at 15:53, Matt Sicker wrote: > Looks like we need to add the bot email as an allowed sender to the list. > Easier said than done, as email appears to use a dynamic address. > Otherwise, I’ve seen the alerts start already > > On Tue, Apr 20, 2021 at 09:27 Fabian Meumertzheim < > meumertzh...@code-intelligence.com> wrote: > > > The first OSS-Fuzz build passed and some bugs have already been created. > > Everything looks good from my side, but let me know if you have any > > questions. > > > > One more thing: Could you perhaps add the following line to the READMEs > of > > compress and imaging? > > > > [](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened=1=proj:apache-commons > > ) > > > > This will give you both an indicator of the fuzzer build status as well > as > > a convenient link to the bugs on the OSS-Fuzz issue tracker. > > > > On Mon, Apr 19, 2021, 12:16 sebb wrote: > > > > > On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig > wrote: > > > > > > > > On 2021-04-18, Stefan Bodewig wrote: > > > > > > > > > I've created https://issues.apache.org/jira/browse/INFRA-21741 if > > you > > > > > want to lend a hand moderating, you may want to add yourself to the > > > > > ticket before the list is created. > > > > > > > > The list has been created, so if you want to receive the fuzz reports > > > > please subscribe to fuzz-testing@commons and one of the intial > > > > moderators will accept the subscription (if we can recognize the > email > > > > address :-). > > > > > > Best to ensure that you use an address that is listed in your LDAP > > account. > > > Visit https://whimsy.apache.org/roster/committer/__self__ to maintain > > the > > > list. > > > Moderators can then use Whimsy to search committers by email address > > > to find you. > > > > > > Also, it looks like the content will appear on lists.a.o (requires > > > login to view): > > > https://lists.apache.org/list.html?fuzz-test...@commons.apache.org > > > > > > There's nothing there at present, so the URL will report an error > > > > Stefan > > > > > > > > - > > > > 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: [all] OSS Fuzz
Looks like we need to add the bot email as an allowed sender to the list. Otherwise, I’ve seen the alerts start already On Tue, Apr 20, 2021 at 09:27 Fabian Meumertzheim < meumertzh...@code-intelligence.com> wrote: > The first OSS-Fuzz build passed and some bugs have already been created. > Everything looks good from my side, but let me know if you have any > questions. > > One more thing: Could you perhaps add the following line to the READMEs of > compress and imaging? > > [](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened=1=proj:apache-commons > ) > > This will give you both an indicator of the fuzzer build status as well as > a convenient link to the bugs on the OSS-Fuzz issue tracker. > > On Mon, Apr 19, 2021, 12:16 sebb wrote: > > > On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig wrote: > > > > > > On 2021-04-18, Stefan Bodewig wrote: > > > > > > > I've created https://issues.apache.org/jira/browse/INFRA-21741 if > you > > > > want to lend a hand moderating, you may want to add yourself to the > > > > ticket before the list is created. > > > > > > The list has been created, so if you want to receive the fuzz reports > > > please subscribe to fuzz-testing@commons and one of the intial > > > moderators will accept the subscription (if we can recognize the email > > > address :-). > > > > Best to ensure that you use an address that is listed in your LDAP > account. > > Visit https://whimsy.apache.org/roster/committer/__self__ to maintain > the > > list. > > Moderators can then use Whimsy to search committers by email address > > to find you. > > > > Also, it looks like the content will appear on lists.a.o (requires > > login to view): > > https://lists.apache.org/list.html?fuzz-test...@commons.apache.org > > > > There's nothing there at present, so the URL will report an error > > > Stefan > > > > > > - > > > 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: [all] OSS Fuzz
The first OSS-Fuzz build passed and some bugs have already been created. Everything looks good from my side, but let me know if you have any questions. One more thing: Could you perhaps add the following line to the READMEs of compress and imaging? [](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened=1=proj:apache-commons ) This will give you both an indicator of the fuzzer build status as well as a convenient link to the bugs on the OSS-Fuzz issue tracker. On Mon, Apr 19, 2021, 12:16 sebb wrote: > On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig wrote: > > > > On 2021-04-18, Stefan Bodewig wrote: > > > > > I've created https://issues.apache.org/jira/browse/INFRA-21741 if you > > > want to lend a hand moderating, you may want to add yourself to the > > > ticket before the list is created. > > > > The list has been created, so if you want to receive the fuzz reports > > please subscribe to fuzz-testing@commons and one of the intial > > moderators will accept the subscription (if we can recognize the email > > address :-). > > Best to ensure that you use an address that is listed in your LDAP account. > Visit https://whimsy.apache.org/roster/committer/__self__ to maintain the > list. > Moderators can then use Whimsy to search committers by email address > to find you. > > Also, it looks like the content will appear on lists.a.o (requires > login to view): > https://lists.apache.org/list.html?fuzz-test...@commons.apache.org > > There's nothing there at present, so the URL will report an error > > Stefan > > > > - > > 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: [all] OSS Fuzz
On Mon, 19 Apr 2021 at 07:54, Stefan Bodewig wrote: > > On 2021-04-18, Stefan Bodewig wrote: > > > I've created https://issues.apache.org/jira/browse/INFRA-21741 if you > > want to lend a hand moderating, you may want to add yourself to the > > ticket before the list is created. > > The list has been created, so if you want to receive the fuzz reports > please subscribe to fuzz-testing@commons and one of the intial > moderators will accept the subscription (if we can recognize the email > address :-). Best to ensure that you use an address that is listed in your LDAP account. Visit https://whimsy.apache.org/roster/committer/__self__ to maintain the list. Moderators can then use Whimsy to search committers by email address to find you. Also, it looks like the content will appear on lists.a.o (requires login to view): https://lists.apache.org/list.html?fuzz-test...@commons.apache.org There's nothing there at present, so the URL will report an error > Stefan > > - > 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: [all] OSS Fuzz
On Mon, Apr 19, 2021 at 8:56 AM Stefan Bodewig wrote: > > Can there be more than one "primary" contact? There is a reason why we > use role based mail aliases and mailing lists, it is pretty likely > people become completely unavailable for a while and I don't want to > block adding people to auto_cc just because I prefer to be offline. I don't know, but as the verification is done by humans, it may not be necessary. I'm pretty sure that anybody with an official @apache.org mail will be able to add themselves. You could probably also just leave a comment on the PR stating that some other GitHub accounts are trusted in this sense. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
On Mon, Apr 19, 2021 at 9:03 AM Stefan Bodewig wrote: > I hope my approval has been enough as I'm not a "reviewer with write > access". I think it will suffice to prove that I have submitted the PRs on behalf of someone affiliated with Apache Commons. The OSS-Fuzz reviewers will review the PR for its technical content. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
On 2021-04-19, Stefan Bodewig wrote: > On 2021-04-18, Fabian Meumertzheim wrote: >> Stefan, if you agree, I would submit the two PRs tomorrow and ask you >> to sign them off on GitHub via a comment on the PR and a link to this >> email thread. > Fine with me. I hope my approval has been enough as I'm not a "reviewer with write access". Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
On 2021-04-18, Fabian Meumertzheim wrote: > Stefan, if you agree, I would submit the two PRs tomorrow and ask you > to sign them off on GitHub via a comment on the PR and a link to this > email thread. Fine with me. Thank you Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
On 2021-04-18, Fabian Meumertzheim wrote: > On Sun, Apr 18, 2021 at 6:22 PM Stefan Bodewig wrote: >> Can probably do, what is the duty of a primary contact? My github >> username is bodewig. > The primary contact may be asked to sign off on PRs to that project in > the OSS-Fuzz repo, in particular if someone needs to be added to the > "auto_ccs" list. I see. Can there be more than one "primary" contact? There is a reason why we use role based mail aliases and mailing lists, it is pretty likely people become completely unavailable for a while and I don't want to block adding people to auto_cc just because I prefer to be offline. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
On 2021-04-18, Stefan Bodewig wrote: > I've created https://issues.apache.org/jira/browse/INFRA-21741 if you > want to lend a hand moderating, you may want to add yourself to the > ticket before the list is created. The list has been created, so if you want to receive the fuzz reports please subscribe to fuzz-testing@commons and one of the intial moderators will accept the subscription (if we can recognize the email address :-). Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
Thank you Stefan! Bruno On Monday, 19 April 2021, 4:22:18 am NZST, Stefan Bodewig wrote: On 2021-04-18, Fabian Meumertzheim wrote: > Anyone who is (or wants to be) a moderator on that list and has a Google > account, please let me know the primary email address so that I can add it > to the "auto_ccs" list for oss-fuzz.com access. > Stefan, would you want to act as the "primary_contact"? That does not > require a Google account, but a GitHub account would be helpful for > interactions with the OSS-Fuzz repo. Can probably do, what is the duty of a primary contact? My github username is bodewig. > I have prepared fuzzers for compress and imaging. Would you want me to set > up both once the list has been properly set up? Given that Bruno expressed interest for imaging, I'd say yes. Thanks Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
Hi Fabian, Yes, please: brunodepaulak at gmail Thanks! Bruno On Monday, 19 April 2021, 7:36:42 am NZST, Fabian Meumertzheim wrote: I have prepared the integrations at https://github.com/CodeIntelligenceTesting/oss-fuzz/tree/commons-compress and https://github.com/CodeIntelligenceTesting/oss-fuzz/tree/commons-imaging. I have included Matt's Google account in the auto_ccs list for both, so you will have access to the full reports. Bruno, do you have a Google account I could add to the auto_ccs list for commons-imaging (and commons-compress, if you want)? Stefan, if you agree, I would submit the two PRs tomorrow and ask you to sign them off on GitHub via a comment on the PR and a link to this email thread. On Sun, Apr 18, 2021 at 6:22 PM Stefan Bodewig wrote: > > On 2021-04-18, Fabian Meumertzheim wrote: > > > Anyone who is (or wants to be) a moderator on that list and has a Google > > account, please let me know the primary email address so that I can add it > > to the "auto_ccs" list for oss-fuzz.com access. > > > Stefan, would you want to act as the "primary_contact"? That does not > > require a Google account, but a GitHub account would be helpful for > > interactions with the OSS-Fuzz repo. > > Can probably do, what is the duty of a primary contact? My github > username is bodewig. > > > I have prepared fuzzers for compress and imaging. Would you want me to set > > up both once the list has been properly set up? > > Given that Bruno expressed interest for imaging, I'd say yes. > > Thanks > > Stefan > > - > 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: [all] OSS Fuzz
I have prepared the integrations at https://github.com/CodeIntelligenceTesting/oss-fuzz/tree/commons-compress and https://github.com/CodeIntelligenceTesting/oss-fuzz/tree/commons-imaging. I have included Matt's Google account in the auto_ccs list for both, so you will have access to the full reports. Bruno, do you have a Google account I could add to the auto_ccs list for commons-imaging (and commons-compress, if you want)? Stefan, if you agree, I would submit the two PRs tomorrow and ask you to sign them off on GitHub via a comment on the PR and a link to this email thread. On Sun, Apr 18, 2021 at 6:22 PM Stefan Bodewig wrote: > > On 2021-04-18, Fabian Meumertzheim wrote: > > > Anyone who is (or wants to be) a moderator on that list and has a Google > > account, please let me know the primary email address so that I can add it > > to the "auto_ccs" list for oss-fuzz.com access. > > > Stefan, would you want to act as the "primary_contact"? That does not > > require a Google account, but a GitHub account would be helpful for > > interactions with the OSS-Fuzz repo. > > Can probably do, what is the duty of a primary contact? My github > username is bodewig. > > > I have prepared fuzzers for compress and imaging. Would you want me to set > > up both once the list has been properly set up? > > Given that Bruno expressed interest for imaging, I'd say yes. > > Thanks > > Stefan > > - > 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: [all] OSS Fuzz
On Sun, Apr 18, 2021 at 6:22 PM Stefan Bodewig wrote: > Can probably do, what is the duty of a primary contact? My github > username is bodewig. The primary contact may be asked to sign off on PRs to that project in the OSS-Fuzz repo, in particular if someone needs to be added to the "auto_ccs" list. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
On 2021-04-18, Fabian Meumertzheim wrote: > Anyone who is (or wants to be) a moderator on that list and has a Google > account, please let me know the primary email address so that I can add it > to the "auto_ccs" list for oss-fuzz.com access. > Stefan, would you want to act as the "primary_contact"? That does not > require a Google account, but a GitHub account would be helpful for > interactions with the OSS-Fuzz repo. Can probably do, what is the duty of a primary contact? My github username is bodewig. > I have prepared fuzzers for compress and imaging. Would you want me to set > up both once the list has been properly set up? Given that Bruno expressed interest for imaging, I'd say yes. Thanks Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
Thanks for creating the list. Anyone who is (or wants to be) a moderator on that list and has a Google account, please let me know the primary email address so that I can add it to the "auto_ccs" list for oss-fuzz.com access. Stefan, would you want to act as the "primary_contact"? That does not require a Google account, but a GitHub account would be helpful for interactions with the OSS-Fuzz repo. I have prepared fuzzers for compress and imaging. Would you want me to set up both once the list has been properly set up? On Sun, Apr 18, 2021, 17:23 Stefan Bodewig wrote: > Hi all > > I've created https://issues.apache.org/jira/browse/INFRA-21741 if you > want to lend a hand moderating, you may want to add yourself to the > ticket before the list is created. > > Thanks > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [all] OSS Fuzz
Hi all I've created https://issues.apache.org/jira/browse/INFRA-21741 if you want to lend a hand moderating, you may want to add yourself to the ticket before the list is created. Thanks Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
On 2021-04-17, Matt Sicker wrote: > I have a Google account I can be CC’d on. I do security engineering > professionally, so I have some experience in the area as well. Thanks Matt, I'll add you as one of the initial moderators as well. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
On 2021-04-17, Fabian Meumertzheim wrote: > Let me describe the restrictions in more detail, including example reports. > Everyone listed under "primary" or "auto_cc" will receive the bugs created > in the issue tracker at [1] in email form and can also add comments by > replying to the email thread, regardless of whether they have a Google > account or not. These bugs only include some basic information such as a > truncated stack trace and a suggested severity. See [2] for an example. > [1] https://bugs.chromium.org/p/oss-fuzz/issues > [2] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32208 > The detailed report, reproducer testcase and crashing revision information > (everything hosted on oss-fuzz.com) requires authentication and thus a > Google account. The detailed report AFAIK even requires authentication > after the bug has become public. I attached an example report as a crudely > exported PDF, just to give you an idea of what information it contains. As our mailing list is set up to strip any non-text part, I've made the PDF you sent available: https://stefan.samaflost.de/staging/ExampleFuzzer.fuzzerTestOneInput.pdf > Regarding privacy concerns: You could consider creating a Google account > specifically for this purpose and only use it to log in to oss-fuzz.com in > a private browsing context. It is perfectly fine for me if Matt and/or others have access. Cheers Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
Le 17/04/2021 à 18:33, Gary Gregory a écrit : > I'll go with the consensus here but I feel that the security list should be > for humans and posts there deserve human attention on an ASAP basis. I've > just seen too many false positives and noise from automated tools over the > years. Let's just give it a try with compress and reevaluate in a couple of month ? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
On Sun, Apr 18, 2021 at 12:43 AM sebb wrote: > How do you ensure that a specific Google account is authorised to view > a particular project? This is exclusively governed by the project's "project.yaml" [1]. An example of such a file is [2]. [1] https://google.github.io/oss-fuzz/getting-started/new-project-guide/#projectyaml [2] https://github.com/google/oss-fuzz/blob/master/projects/openssl/project.yaml > > We also need to ensure continuity of access should an existing Google > user leave the project or be unavailable. How is that managed? This is usually managed through pull requests to the OSS-Fuzz repo, which are usually swiftly acted upon. If not performed by the "primary_contact" for a project directly, they are contacted to verify such changes. AFAIK that is the only difference between a "primary_contact" and an "auto_ccs" member. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
Can we make a Google group or shared Google account for the commons PMC? On Sat, Apr 17, 2021 at 17:43 sebb wrote: > On Sat, 17 Apr 2021 at 18:05, Fabian Meumertzheim > wrote: > > > > On Sat, Apr 17, 2021 at 3:58 PM Stefan Bodewig > wrote: > > > > > > I'm not sure I understand this. AFAIU I could never become a "primary" > > > or an "auto_cc" as I will not create a Google account. Do we need to > > > have one? In that case somebody who doesn't share my personal set of > > > allergic reactions may want to act as primary. > > > > > > But how does that translate to using a mailing list as recipient of > > > reports? The section you link says you need a google account to "get > > > full access" - I don't think the list will need "full access". > > > > Let me describe the restrictions in more detail, including example > reports. Everyone listed under "primary" or "auto_cc" will receive the bugs > created in the issue tracker at [1] in email form and can also add comments > by replying to the email thread, regardless of whether they have a Google > account or not. These bugs only include some basic information such as a > truncated stack trace and a suggested severity. See [2] for an example. > > > > The detailed report, reproducer testcase and crashing revision > information (everything hosted on oss-fuzz.com) requires authentication > and thus a Google account. The detailed report AFAIK even requires > authentication after the bug has become public. I attached an example > report as a crudely exported PDF, just to give you an idea of what > information it contains. Additionally, you get access to the raw fuzzer > logs, corpus as well as the option to manually upload a testcase. > > > > Regarding privacy concerns: You could consider creating a Google account > specifically for this purpose and only use it to log in to oss-fuzz.com > in a private browsing context. > > How do you ensure that a specific Google account is authorised to view > a particular project? > > We also need to ensure continuity of access should an existing Google > user leave the project or be unavailable. How is that managed? > > > Fabian > > > > [1] https://bugs.chromium.org/p/oss-fuzz/issues > > [2] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32208 > > > > - > > 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: [all] OSS Fuzz
On Sat, 17 Apr 2021 at 18:05, Fabian Meumertzheim wrote: > > On Sat, Apr 17, 2021 at 3:58 PM Stefan Bodewig wrote: > > > > I'm not sure I understand this. AFAIU I could never become a "primary" > > or an "auto_cc" as I will not create a Google account. Do we need to > > have one? In that case somebody who doesn't share my personal set of > > allergic reactions may want to act as primary. > > > > But how does that translate to using a mailing list as recipient of > > reports? The section you link says you need a google account to "get > > full access" - I don't think the list will need "full access". > > Let me describe the restrictions in more detail, including example reports. > Everyone listed under "primary" or "auto_cc" will receive the bugs created in > the issue tracker at [1] in email form and can also add comments by replying > to the email thread, regardless of whether they have a Google account or not. > These bugs only include some basic information such as a truncated stack > trace and a suggested severity. See [2] for an example. > > The detailed report, reproducer testcase and crashing revision information > (everything hosted on oss-fuzz.com) requires authentication and thus a Google > account. The detailed report AFAIK even requires authentication after the bug > has become public. I attached an example report as a crudely exported PDF, > just to give you an idea of what information it contains. Additionally, you > get access to the raw fuzzer logs, corpus as well as the option to manually > upload a testcase. > > Regarding privacy concerns: You could consider creating a Google account > specifically for this purpose and only use it to log in to oss-fuzz.com in a > private browsing context. How do you ensure that a specific Google account is authorised to view a particular project? We also need to ensure continuity of access should an existing Google user leave the project or be unavailable. How is that managed? > Fabian > > [1] https://bugs.chromium.org/p/oss-fuzz/issues > [2] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32208 > > - > 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: [all] OSS Fuzz
On Sat, 17 Apr 2021 at 17:33, Gary Gregory wrote: > > I'll go with the consensus here but I feel that the security list should be > for humans and posts there deserve human attention on an ASAP basis. I've > just seen too many false positives and noise from automated tools over the > years. Agreed. > Gary > > On Sat, Apr 17, 2021, 09:48 Stefan Bodewig wrote: > > > On 2021-04-13, Mark Thomas wrote: > > > > > On 13/04/2021 17:49, Stefan Bodewig wrote: > > > > > > > > > >> Fabian has offered to set up OSS Fuzz for Compress. Given that the > > >> issues OSS Fuzz detects may or may not be security sensitive, I don't > > >> feel it would be a good idea to have the tool send reports to a public > > >> mailing list. Therefore I propose to create another subscription > > >> moderated list just for these kinds of reports. I'm afraid it could be > > >> too noisy for security@commons. > > > > > Following the "split by audience, not by topic" guideline, I'd suggest > > > using security@commons.a.o rather than a separate list. Much, much > > > bigger projects than Compress use OSS Fuzz and direct traffic to their > > > security list where it seems to be manageable. > > > > With more projects jumping it this may become more traffic. Given that > > at least one subscriber of security@ (Gary) is strongly against using > > that list, I don't want to force it on him. > > > > Stefan > > > > - > > 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: [all] OSS Fuzz
On Sat, Apr 17, 2021 at 3:58 PM Stefan Bodewig wrote: > > I'm not sure I understand this. AFAIU I could never become a "primary" > or an "auto_cc" as I will not create a Google account. Do we need to > have one? In that case somebody who doesn't share my personal set of > allergic reactions may want to act as primary. > > But how does that translate to using a mailing list as recipient of > reports? The section you link says you need a google account to "get > full access" - I don't think the list will need "full access". Let me describe the restrictions in more detail, including example reports. Everyone listed under "primary" or "auto_cc" will receive the bugs created in the issue tracker at [1] in email form and can also add comments by replying to the email thread, regardless of whether they have a Google account or not. These bugs only include some basic information such as a truncated stack trace and a suggested severity. See [2] for an example. The detailed report, reproducer testcase and crashing revision information (everything hosted on oss-fuzz.com) requires authentication and thus a Google account. The detailed report AFAIK even requires authentication after the bug has become public. I attached an example report as a crudely exported PDF, just to give you an idea of what information it contains. Additionally, you get access to the raw fuzzer logs, corpus as well as the option to manually upload a testcase. Regarding privacy concerns: You could consider creating a Google account specifically for this purpose and only use it to log in to oss-fuzz.com in a private browsing context. Fabian [1] https://bugs.chromium.org/p/oss-fuzz/issues [2] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32208 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
I'll go with the consensus here but I feel that the security list should be for humans and posts there deserve human attention on an ASAP basis. I've just seen too many false positives and noise from automated tools over the years. Gary On Sat, Apr 17, 2021, 09:48 Stefan Bodewig wrote: > On 2021-04-13, Mark Thomas wrote: > > > On 13/04/2021 17:49, Stefan Bodewig wrote: > > > > > >> Fabian has offered to set up OSS Fuzz for Compress. Given that the > >> issues OSS Fuzz detects may or may not be security sensitive, I don't > >> feel it would be a good idea to have the tool send reports to a public > >> mailing list. Therefore I propose to create another subscription > >> moderated list just for these kinds of reports. I'm afraid it could be > >> too noisy for security@commons. > > > Following the "split by audience, not by topic" guideline, I'd suggest > > using security@commons.a.o rather than a separate list. Much, much > > bigger projects than Compress use OSS Fuzz and direct traffic to their > > security list where it seems to be manageable. > > With more projects jumping it this may become more traffic. Given that > at least one subscriber of security@ (Gary) is strongly against using > that list, I don't want to force it on him. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [all] OSS Fuzz
I have a Google account I can be CC’d on. I do security engineering professionally, so I have some experience in the area as well. On Sat, Apr 17, 2021 at 08:58 Stefan Bodewig wrote: > On 2021-04-15, Fabian Meumertzheim wrote: > > > Just to keep the following in mind: Full access to bug reports and > > reproducers requires a Google account (which can be associated with > > any existing non-list email address). At least the moderators of the > > list would therefore have to be listed explicitly in the project's > > YAML file [1] in the OSS-Fuzz repo, in addition to the new mailing > > list. > > > [1] > https://google.github.io/oss-fuzz/getting-started/new-project-guide/#primary > > I'm not sure I understand this. AFAIU I could never become a "primary" > or an "auto_cc" as I will not create a Google account. Do we need to > have one? In that case somebody who doesn't share my personal set of > allergic reactions may want to act as primary. > > But how does that translate to using a mailing list as recipient of > reports? The section you link says you need a google account to "get > full access" - I don't think the list will need "full access". > > Stefan > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [all] OSS Fuzz
On 2021-04-15, Fabian Meumertzheim wrote: > Just to keep the following in mind: Full access to bug reports and > reproducers requires a Google account (which can be associated with > any existing non-list email address). At least the moderators of the > list would therefore have to be listed explicitly in the project's > YAML file [1] in the OSS-Fuzz repo, in addition to the new mailing > list. > [1] > https://google.github.io/oss-fuzz/getting-started/new-project-guide/#primary I'm not sure I understand this. AFAIU I could never become a "primary" or an "auto_cc" as I will not create a Google account. Do we need to have one? In that case somebody who doesn't share my personal set of allergic reactions may want to act as primary. But how does that translate to using a mailing list as recipient of reports? The section you link says you need a google account to "get full access" - I don't think the list will need "full access". Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
On 2021-04-13, Gary Gregory wrote: > Please don't use @security for automated emails, that ML IMO should be for > humans. > If you want to setup a new ML for bots that's fine, we can direct GitHub's > Dependanot emails there if GitHub allows for that. I don't believe dependabot and the results of fuzz testing share an audience. Dependabot mails are by no means sensitive (the PRs are public anyway) so there is no need for restricting the subscription to the messages it creates. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
On 2021-04-13, Mark Thomas wrote: > On 13/04/2021 17:49, Stefan Bodewig wrote: > >> Fabian has offered to set up OSS Fuzz for Compress. Given that the >> issues OSS Fuzz detects may or may not be security sensitive, I don't >> feel it would be a good idea to have the tool send reports to a public >> mailing list. Therefore I propose to create another subscription >> moderated list just for these kinds of reports. I'm afraid it could be >> too noisy for security@commons. > Following the "split by audience, not by topic" guideline, I'd suggest > using security@commons.a.o rather than a separate list. Much, much > bigger projects than Compress use OSS Fuzz and direct traffic to their > security list where it seems to be manageable. With more projects jumping it this may become more traffic. Given that at least one subscriber of security@ (Gary) is strongly against using that list, I don't want to force it on him. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
+1 to fuzz. Fuzzing is widely used in many open source projects and it helped a
lot in Compress.
For the mailing list, many projects use Security. And creating a new one is OK
for me.
> I'd add myself as a moderator but we will need more moderators.
If we need moderators, count me in.
cheers,
Lee
On 4 15 2021, at 2:11, Fabian Meumertzheim
wrote:
> Just to keep the following in mind: Full access to bug reports and
> reproducers requires a Google account (which can be associated with
> any existing non-list email address). At least the moderators of the
> list would therefore have to be listed explicitly in the project's
> YAML file [1] in the OSS-Fuzz repo, in addition to the new mailing
> list.
>
> [1]
> https://google.github.io/oss-fuzz/getting-started/new-project-guide/#primary
> On Wed, Apr 14, 2021 at 10:57 PM Matt Juntunen
> wrote:
> >
> > For what it's worth, commons-geometry just added IO functionality so I
> > would be interested in fuzzing for that as well. I do not have a preference
> > on the email list question.
> >
> > Regards,
> > Matt J
> >
> > From: Fabian Meumertzheim
> > Sent: Wednesday, April 14, 2021 12:13 PM
> > To: Commons Developers List
> > Subject: Re: [all] OSS Fuzz
> >
> > On Wed, Apr 14, 2021, 17:14 Matt Sicker wrote:
> >
> > > Would the undeclared runtime exceptions be "fixable" for the fuzzing
> > > tool if the methods declared their runtime exceptions being thrown? Or
> > > the javadocs? As in, this tool is looking for exceptional conditions
> > > that don't appear to be intentional?
> > >
> >
> > It is, but you have to tell it what is intentional and how to invoke your
> > API in interesting ways by supplying a fuzz target. As an example, the
> > following fuzz target found the infinite loop in Compress:
> >
> > public static void fuzzerTestOneInput(byte[] input) {
> > try {
> > new TarFile(input).close();
> > } catch (IOException ignored) {}
> > }
> >
> > OSS-Fuzz integration entails writing these fuzz targets, which can be
> > straightforward (as for compress) or a bit more involved (e.g. finding the
> > right properties to check for collections). Think of these fuzz targets as
> > property-based unit tests for which you don't have to supply the test data
> > yourself.
> >
> >
> > > I've briefly looked at OSS-Fuzz, and it certainly looks helpful. I
> > > think codec, compress, collections (probably), io, net, jelly, jexl,
> > > pool, and probably a few others would be interesting to see fuzzed
> > > (for different reasons; some for handling XML or other languages,
> > > others for concurrency issues, serializability, etc).
> > >
> > > On Wed, 14 Apr 2021 at 01:42, Fabian Meumertzheim
> > > wrote:
> > > >
> > > > As I am not familiar with the structure of your mailing lists and also
> > > > can't give a meaningful estimate of the ratio of normal bugs to
> > > > security issues we will find, I will only provide the following
> > > > general points of information on OSS-Fuzz:
> > > >
> > > > * By design, fuzzing produces little to no false positives. Unless a
> > > > library maintains non-trivial global state that is not accounted for
> > > > in the fuzz target, all OSS-Fuzz findings should at least be fully
> > > > reproducible reports of normal bugs, including stack traces and
> > > > minimized reproducing inputs.
> > > >
> > > > * Deduplicating certain kinds of issues may be difficult to do
> > > > automatically, so some root causes may lead to multiple reports filed.
> > > > Since OSS-Fuzz automatically detects when a bug has been fixed
> > > > upstream, acting on one of the reports would still close all the
> > > > others without additional triage work.
> > > >
> > > > * OSS-Fuzz considers bugs and security issues fixed once it has
> > > > determined that they do no longer reproduce in the upstream project,
> > > > which happens roughly a day after the fix has been made in the git/svn
> > > > repository. After the first few bugs, most new bugs are usually found
> > > > in unreleased commits, where this wouldn't be an issue at all. In case
> > > > OSS-Fuzz finds a security issue that reproduces in a release, just
> > > > keep in mind that the "patch gap" between the fixing commit and the
> > > > point release should be kept as short as possible.
&
Re: [all] OSS Fuzz
Just to keep the following in mind: Full access to bug reports and
reproducers requires a Google account (which can be associated with
any existing non-list email address). At least the moderators of the
list would therefore have to be listed explicitly in the project's
YAML file [1] in the OSS-Fuzz repo, in addition to the new mailing
list.
[1] https://google.github.io/oss-fuzz/getting-started/new-project-guide/#primary
On Wed, Apr 14, 2021 at 10:57 PM Matt Juntunen
wrote:
>
> For what it's worth, commons-geometry just added IO functionality so I would
> be interested in fuzzing for that as well. I do not have a preference on the
> email list question.
>
> Regards,
> Matt J
>
> From: Fabian Meumertzheim
> Sent: Wednesday, April 14, 2021 12:13 PM
> To: Commons Developers List
> Subject: Re: [all] OSS Fuzz
>
> On Wed, Apr 14, 2021, 17:14 Matt Sicker wrote:
>
> > Would the undeclared runtime exceptions be "fixable" for the fuzzing
> > tool if the methods declared their runtime exceptions being thrown? Or
> > the javadocs? As in, this tool is looking for exceptional conditions
> > that don't appear to be intentional?
> >
>
> It is, but you have to tell it what is intentional and how to invoke your
> API in interesting ways by supplying a fuzz target. As an example, the
> following fuzz target found the infinite loop in Compress:
>
> public static void fuzzerTestOneInput(byte[] input) {
> try {
> new TarFile(input).close();
> } catch (IOException ignored) {}
> }
>
> OSS-Fuzz integration entails writing these fuzz targets, which can be
> straightforward (as for compress) or a bit more involved (e.g. finding the
> right properties to check for collections). Think of these fuzz targets as
> property-based unit tests for which you don't have to supply the test data
> yourself.
>
>
> > I've briefly looked at OSS-Fuzz, and it certainly looks helpful. I
> > think codec, compress, collections (probably), io, net, jelly, jexl,
> > pool, and probably a few others would be interesting to see fuzzed
> > (for different reasons; some for handling XML or other languages,
> > others for concurrency issues, serializability, etc).
> >
> > On Wed, 14 Apr 2021 at 01:42, Fabian Meumertzheim
> > wrote:
> > >
> > > As I am not familiar with the structure of your mailing lists and also
> > > can't give a meaningful estimate of the ratio of normal bugs to
> > > security issues we will find, I will only provide the following
> > > general points of information on OSS-Fuzz:
> > >
> > > * By design, fuzzing produces little to no false positives. Unless a
> > > library maintains non-trivial global state that is not accounted for
> > > in the fuzz target, all OSS-Fuzz findings should at least be fully
> > > reproducible reports of normal bugs, including stack traces and
> > > minimized reproducing inputs.
> > >
> > > * Deduplicating certain kinds of issues may be difficult to do
> > > automatically, so some root causes may lead to multiple reports filed.
> > > Since OSS-Fuzz automatically detects when a bug has been fixed
> > > upstream, acting on one of the reports would still close all the
> > > others without additional triage work.
> > >
> > > * OSS-Fuzz considers bugs and security issues fixed once it has
> > > determined that they do no longer reproduce in the upstream project,
> > > which happens roughly a day after the fix has been made in the git/svn
> > > repository. After the first few bugs, most new bugs are usually found
> > > in unreleased commits, where this wouldn't be an issue at all. In case
> > > OSS-Fuzz finds a security issue that reproduces in a release, just
> > > keep in mind that the "patch gap" between the fixing commit and the
> > > point release should be kept as short as possible.
> > >
> > > * From my experience with OSS-Fuzz projects in other languages as well
> > > as the first onboarded Java projects (e.g. various Jackson parsers),
> > > you should expect to see a number of purely functional bugs (e.g.
> > > undeclared runtime exceptions) over the first days before the fuzzer
> > > gets to the more interesting bugs (e.g. OutOfMemoryError and infinite
> > > loops). While it would be possible to just not report purely
> > > functional bugs, I would not recommend to do this as it hurts the
> > > overall fuzzer performance.
> > >
> > > * Depending on the project, we may be able to define additional,
> > > domain-specific class
Re: [all] OSS Fuzz
For what it's worth, commons-geometry just added IO functionality so I would be
interested in fuzzing for that as well. I do not have a preference on the email
list question.
Regards,
Matt J
From: Fabian Meumertzheim
Sent: Wednesday, April 14, 2021 12:13 PM
To: Commons Developers List
Subject: Re: [all] OSS Fuzz
On Wed, Apr 14, 2021, 17:14 Matt Sicker wrote:
> Would the undeclared runtime exceptions be "fixable" for the fuzzing
> tool if the methods declared their runtime exceptions being thrown? Or
> the javadocs? As in, this tool is looking for exceptional conditions
> that don't appear to be intentional?
>
It is, but you have to tell it what is intentional and how to invoke your
API in interesting ways by supplying a fuzz target. As an example, the
following fuzz target found the infinite loop in Compress:
public static void fuzzerTestOneInput(byte[] input) {
try {
new TarFile(input).close();
} catch (IOException ignored) {}
}
OSS-Fuzz integration entails writing these fuzz targets, which can be
straightforward (as for compress) or a bit more involved (e.g. finding the
right properties to check for collections). Think of these fuzz targets as
property-based unit tests for which you don't have to supply the test data
yourself.
> I've briefly looked at OSS-Fuzz, and it certainly looks helpful. I
> think codec, compress, collections (probably), io, net, jelly, jexl,
> pool, and probably a few others would be interesting to see fuzzed
> (for different reasons; some for handling XML or other languages,
> others for concurrency issues, serializability, etc).
>
> On Wed, 14 Apr 2021 at 01:42, Fabian Meumertzheim
> wrote:
> >
> > As I am not familiar with the structure of your mailing lists and also
> > can't give a meaningful estimate of the ratio of normal bugs to
> > security issues we will find, I will only provide the following
> > general points of information on OSS-Fuzz:
> >
> > * By design, fuzzing produces little to no false positives. Unless a
> > library maintains non-trivial global state that is not accounted for
> > in the fuzz target, all OSS-Fuzz findings should at least be fully
> > reproducible reports of normal bugs, including stack traces and
> > minimized reproducing inputs.
> >
> > * Deduplicating certain kinds of issues may be difficult to do
> > automatically, so some root causes may lead to multiple reports filed.
> > Since OSS-Fuzz automatically detects when a bug has been fixed
> > upstream, acting on one of the reports would still close all the
> > others without additional triage work.
> >
> > * OSS-Fuzz considers bugs and security issues fixed once it has
> > determined that they do no longer reproduce in the upstream project,
> > which happens roughly a day after the fix has been made in the git/svn
> > repository. After the first few bugs, most new bugs are usually found
> > in unreleased commits, where this wouldn't be an issue at all. In case
> > OSS-Fuzz finds a security issue that reproduces in a release, just
> > keep in mind that the "patch gap" between the fixing commit and the
> > point release should be kept as short as possible.
> >
> > * From my experience with OSS-Fuzz projects in other languages as well
> > as the first onboarded Java projects (e.g. various Jackson parsers),
> > you should expect to see a number of purely functional bugs (e.g.
> > undeclared runtime exceptions) over the first days before the fuzzer
> > gets to the more interesting bugs (e.g. OutOfMemoryError and infinite
> > loops). While it would be possible to just not report purely
> > functional bugs, I would not recommend to do this as it hurts the
> > overall fuzzer performance.
> >
> > * Depending on the project, we may be able to define additional,
> > domain-specific classes of security issues that the fuzzer could check
> > for. As an example, I'm pretty confident that OSS-Fuzz would have
> > found CVE-2021-29425 (Possible limited path traversal vulnerability in
> > Apache Commons IO) with a proper fuzz target.
> >
> > I'll monitor this thread in case you have any more questions on
> > OSS-Fuzz or its JVM fuzzer Jazzer.
> >
> >
> > Fabian
> >
> > On Wed, Apr 14, 2021 at 4:59 AM Bruno P. Kinoshita
> wrote:
> > >
> > > +1 for oss fuzz. Fabian also got in contact a few days earlier, and
> asked me about using it with Commons Imaging. I told him it had to be
> discussed here first, but that I thought it could be useful (we are parsing
> several image file formats, probably a few things could be improved).
> > >
> > >
> > > As for the
Re: [all] OSS Fuzz
On Wed, Apr 14, 2021, 17:14 Matt Sicker wrote:
> Would the undeclared runtime exceptions be "fixable" for the fuzzing
> tool if the methods declared their runtime exceptions being thrown? Or
> the javadocs? As in, this tool is looking for exceptional conditions
> that don't appear to be intentional?
>
It is, but you have to tell it what is intentional and how to invoke your
API in interesting ways by supplying a fuzz target. As an example, the
following fuzz target found the infinite loop in Compress:
public static void fuzzerTestOneInput(byte[] input) {
try {
new TarFile(input).close();
} catch (IOException ignored) {}
}
OSS-Fuzz integration entails writing these fuzz targets, which can be
straightforward (as for compress) or a bit more involved (e.g. finding the
right properties to check for collections). Think of these fuzz targets as
property-based unit tests for which you don't have to supply the test data
yourself.
> I've briefly looked at OSS-Fuzz, and it certainly looks helpful. I
> think codec, compress, collections (probably), io, net, jelly, jexl,
> pool, and probably a few others would be interesting to see fuzzed
> (for different reasons; some for handling XML or other languages,
> others for concurrency issues, serializability, etc).
>
> On Wed, 14 Apr 2021 at 01:42, Fabian Meumertzheim
> wrote:
> >
> > As I am not familiar with the structure of your mailing lists and also
> > can't give a meaningful estimate of the ratio of normal bugs to
> > security issues we will find, I will only provide the following
> > general points of information on OSS-Fuzz:
> >
> > * By design, fuzzing produces little to no false positives. Unless a
> > library maintains non-trivial global state that is not accounted for
> > in the fuzz target, all OSS-Fuzz findings should at least be fully
> > reproducible reports of normal bugs, including stack traces and
> > minimized reproducing inputs.
> >
> > * Deduplicating certain kinds of issues may be difficult to do
> > automatically, so some root causes may lead to multiple reports filed.
> > Since OSS-Fuzz automatically detects when a bug has been fixed
> > upstream, acting on one of the reports would still close all the
> > others without additional triage work.
> >
> > * OSS-Fuzz considers bugs and security issues fixed once it has
> > determined that they do no longer reproduce in the upstream project,
> > which happens roughly a day after the fix has been made in the git/svn
> > repository. After the first few bugs, most new bugs are usually found
> > in unreleased commits, where this wouldn't be an issue at all. In case
> > OSS-Fuzz finds a security issue that reproduces in a release, just
> > keep in mind that the "patch gap" between the fixing commit and the
> > point release should be kept as short as possible.
> >
> > * From my experience with OSS-Fuzz projects in other languages as well
> > as the first onboarded Java projects (e.g. various Jackson parsers),
> > you should expect to see a number of purely functional bugs (e.g.
> > undeclared runtime exceptions) over the first days before the fuzzer
> > gets to the more interesting bugs (e.g. OutOfMemoryError and infinite
> > loops). While it would be possible to just not report purely
> > functional bugs, I would not recommend to do this as it hurts the
> > overall fuzzer performance.
> >
> > * Depending on the project, we may be able to define additional,
> > domain-specific classes of security issues that the fuzzer could check
> > for. As an example, I'm pretty confident that OSS-Fuzz would have
> > found CVE-2021-29425 (Possible limited path traversal vulnerability in
> > Apache Commons IO) with a proper fuzz target.
> >
> > I'll monitor this thread in case you have any more questions on
> > OSS-Fuzz or its JVM fuzzer Jazzer.
> >
> >
> > Fabian
> >
> > On Wed, Apr 14, 2021 at 4:59 AM Bruno P. Kinoshita
> wrote:
> > >
> > > +1 for oss fuzz. Fabian also got in contact a few days earlier, and
> asked me about using it with Commons Imaging. I told him it had to be
> discussed here first, but that I thought it could be useful (we are parsing
> several image file formats, probably a few things could be improved).
> > >
> > >
> > > As for the mailing list, for me it depends on the amount of messages,
> and false-positives. i.e. if we get 50 e-mails in security@commons in one
> week, and turns out only 1 is actually a security issue, and the others are
> either normal bugs and no bugs, then eventually I think I'd just create a
> filter to move all the security@commons to a folder and have a look
> someday.
> > >
> > >
> > > I think we don't have any idea how many e-mails we might get enabling
> it for one or for a few components. So I'd be OK with
> > >
> > > - sending e-mails to security@commons initially, but if it spams the
> list with non-security related e-mails, then move to a separate mailing
> list; OR
> > > - create the new mailing list (probably private too? until we filter
> the
Re: [all] OSS Fuzz
Would the undeclared runtime exceptions be "fixable" for the fuzzing tool if the methods declared their runtime exceptions being thrown? Or the javadocs? As in, this tool is looking for exceptional conditions that don't appear to be intentional? I've briefly looked at OSS-Fuzz, and it certainly looks helpful. I think codec, compress, collections (probably), io, net, jelly, jexl, pool, and probably a few others would be interesting to see fuzzed (for different reasons; some for handling XML or other languages, others for concurrency issues, serializability, etc). On Wed, 14 Apr 2021 at 01:42, Fabian Meumertzheim wrote: > > As I am not familiar with the structure of your mailing lists and also > can't give a meaningful estimate of the ratio of normal bugs to > security issues we will find, I will only provide the following > general points of information on OSS-Fuzz: > > * By design, fuzzing produces little to no false positives. Unless a > library maintains non-trivial global state that is not accounted for > in the fuzz target, all OSS-Fuzz findings should at least be fully > reproducible reports of normal bugs, including stack traces and > minimized reproducing inputs. > > * Deduplicating certain kinds of issues may be difficult to do > automatically, so some root causes may lead to multiple reports filed. > Since OSS-Fuzz automatically detects when a bug has been fixed > upstream, acting on one of the reports would still close all the > others without additional triage work. > > * OSS-Fuzz considers bugs and security issues fixed once it has > determined that they do no longer reproduce in the upstream project, > which happens roughly a day after the fix has been made in the git/svn > repository. After the first few bugs, most new bugs are usually found > in unreleased commits, where this wouldn't be an issue at all. In case > OSS-Fuzz finds a security issue that reproduces in a release, just > keep in mind that the "patch gap" between the fixing commit and the > point release should be kept as short as possible. > > * From my experience with OSS-Fuzz projects in other languages as well > as the first onboarded Java projects (e.g. various Jackson parsers), > you should expect to see a number of purely functional bugs (e.g. > undeclared runtime exceptions) over the first days before the fuzzer > gets to the more interesting bugs (e.g. OutOfMemoryError and infinite > loops). While it would be possible to just not report purely > functional bugs, I would not recommend to do this as it hurts the > overall fuzzer performance. > > * Depending on the project, we may be able to define additional, > domain-specific classes of security issues that the fuzzer could check > for. As an example, I'm pretty confident that OSS-Fuzz would have > found CVE-2021-29425 (Possible limited path traversal vulnerability in > Apache Commons IO) with a proper fuzz target. > > I'll monitor this thread in case you have any more questions on > OSS-Fuzz or its JVM fuzzer Jazzer. > > > Fabian > > On Wed, Apr 14, 2021 at 4:59 AM Bruno P. Kinoshita wrote: > > > > +1 for oss fuzz. Fabian also got in contact a few days earlier, and asked > > me about using it with Commons Imaging. I told him it had to be discussed > > here first, but that I thought it could be useful (we are parsing several > > image file formats, probably a few things could be improved). > > > > > > As for the mailing list, for me it depends on the amount of messages, and > > false-positives. i.e. if we get 50 e-mails in security@commons in one week, > > and turns out only 1 is actually a security issue, and the others are > > either normal bugs and no bugs, then eventually I think I'd just create a > > filter to move all the security@commons to a folder and have a look someday. > > > > > > I think we don't have any idea how many e-mails we might get enabling it > > for one or for a few components. So I'd be OK with > > > > - sending e-mails to security@commons initially, but if it spams the list > > with non-security related e-mails, then move to a separate mailing list; OR > > - create the new mailing list (probably private too? until we filter the > > issues?) and use it for a few weeks/months. If the traffic is low, or most > > issues are really security related, then move to security@commons if others > > agree > > > > Either way would be OK for me. > > > > Cheers > > Bruno > > > > > > On Wednesday, 14 April 2021, 4:49:31 am NZST, Stefan Bodewig > > wrote: > > > > Hi all > > > > I want to pick up (and finish) the discussion that started in > > Compress[1]. > > > > Short Recap: > > > > > > OSS Fuzz[2] runs fuzz testing for open source projects by invoking > > methods of our code with random data looking for unexpected outcomes > > (undeclared exceptions or worse code that never returns because it is > > stuck in an infinite loop for example). > > > > For Compress Fabian (who started [1]) has already identified and > > reported
Re: [all] OSS Fuzz
As I am not familiar with the structure of your mailing lists and also can't give a meaningful estimate of the ratio of normal bugs to security issues we will find, I will only provide the following general points of information on OSS-Fuzz: * By design, fuzzing produces little to no false positives. Unless a library maintains non-trivial global state that is not accounted for in the fuzz target, all OSS-Fuzz findings should at least be fully reproducible reports of normal bugs, including stack traces and minimized reproducing inputs. * Deduplicating certain kinds of issues may be difficult to do automatically, so some root causes may lead to multiple reports filed. Since OSS-Fuzz automatically detects when a bug has been fixed upstream, acting on one of the reports would still close all the others without additional triage work. * OSS-Fuzz considers bugs and security issues fixed once it has determined that they do no longer reproduce in the upstream project, which happens roughly a day after the fix has been made in the git/svn repository. After the first few bugs, most new bugs are usually found in unreleased commits, where this wouldn't be an issue at all. In case OSS-Fuzz finds a security issue that reproduces in a release, just keep in mind that the "patch gap" between the fixing commit and the point release should be kept as short as possible. * From my experience with OSS-Fuzz projects in other languages as well as the first onboarded Java projects (e.g. various Jackson parsers), you should expect to see a number of purely functional bugs (e.g. undeclared runtime exceptions) over the first days before the fuzzer gets to the more interesting bugs (e.g. OutOfMemoryError and infinite loops). While it would be possible to just not report purely functional bugs, I would not recommend to do this as it hurts the overall fuzzer performance. * Depending on the project, we may be able to define additional, domain-specific classes of security issues that the fuzzer could check for. As an example, I'm pretty confident that OSS-Fuzz would have found CVE-2021-29425 (Possible limited path traversal vulnerability in Apache Commons IO) with a proper fuzz target. I'll monitor this thread in case you have any more questions on OSS-Fuzz or its JVM fuzzer Jazzer. Fabian On Wed, Apr 14, 2021 at 4:59 AM Bruno P. Kinoshita wrote: > > +1 for oss fuzz. Fabian also got in contact a few days earlier, and asked me > about using it with Commons Imaging. I told him it had to be discussed here > first, but that I thought it could be useful (we are parsing several image > file formats, probably a few things could be improved). > > > As for the mailing list, for me it depends on the amount of messages, and > false-positives. i.e. if we get 50 e-mails in security@commons in one week, > and turns out only 1 is actually a security issue, and the others are either > normal bugs and no bugs, then eventually I think I'd just create a filter to > move all the security@commons to a folder and have a look someday. > > > I think we don't have any idea how many e-mails we might get enabling it for > one or for a few components. So I'd be OK with > > - sending e-mails to security@commons initially, but if it spams the list > with non-security related e-mails, then move to a separate mailing list; OR > - create the new mailing list (probably private too? until we filter the > issues?) and use it for a few weeks/months. If the traffic is low, or most > issues are really security related, then move to security@commons if others > agree > > Either way would be OK for me. > > Cheers > Bruno > > > On Wednesday, 14 April 2021, 4:49:31 am NZST, Stefan Bodewig > wrote: > > Hi all > > I want to pick up (and finish) the discussion that started in > Compress[1]. > > Short Recap: > > > OSS Fuzz[2] runs fuzz testing for open source projects by invoking > methods of our code with random data looking for unexpected outcomes > (undeclared exceptions or worse code that never returns because it is > stuck in an infinite loop for example). > > For Compress Fabian (who started [1]) has already identified and > reported several issues, one of which would have become a CVE if the > code in question had been part of any release of Compress. In the past > other people have run different fuzzers and found "interesting" results > in Compress as well. > > Compress may be especially vulnerable as it basically tries to make > sense out of a bunch of user supplied bytes - but the same is probably > true for codec or imaging for example. > > Fabian has offered to set up OSS Fuzz for Compress. Given that the > issues OSS Fuzz detects may or may not be security sensitive, I don't > feel it would be a good idea to have the tool send reports to a public > mailing list. Therefore I propose to create another subscription > moderated list just for these kinds of reports. I'm afraid it could be > too noisy for security@commons. > >
Re: [all] OSS Fuzz
+1 for oss fuzz. Fabian also got in contact a few days earlier, and asked me about using it with Commons Imaging. I told him it had to be discussed here first, but that I thought it could be useful (we are parsing several image file formats, probably a few things could be improved). As for the mailing list, for me it depends on the amount of messages, and false-positives. i.e. if we get 50 e-mails in security@commons in one week, and turns out only 1 is actually a security issue, and the others are either normal bugs and no bugs, then eventually I think I'd just create a filter to move all the security@commons to a folder and have a look someday. I think we don't have any idea how many e-mails we might get enabling it for one or for a few components. So I'd be OK with - sending e-mails to security@commons initially, but if it spams the list with non-security related e-mails, then move to a separate mailing list; OR - create the new mailing list (probably private too? until we filter the issues?) and use it for a few weeks/months. If the traffic is low, or most issues are really security related, then move to security@commons if others agree Either way would be OK for me. Cheers Bruno On Wednesday, 14 April 2021, 4:49:31 am NZST, Stefan Bodewig wrote: Hi all I want to pick up (and finish) the discussion that started in Compress[1]. Short Recap: OSS Fuzz[2] runs fuzz testing for open source projects by invoking methods of our code with random data looking for unexpected outcomes (undeclared exceptions or worse code that never returns because it is stuck in an infinite loop for example). For Compress Fabian (who started [1]) has already identified and reported several issues, one of which would have become a CVE if the code in question had been part of any release of Compress. In the past other people have run different fuzzers and found "interesting" results in Compress as well. Compress may be especially vulnerable as it basically tries to make sense out of a bunch of user supplied bytes - but the same is probably true for codec or imaging for example. Fabian has offered to set up OSS Fuzz for Compress. Given that the issues OSS Fuzz detects may or may not be security sensitive, I don't feel it would be a good idea to have the tool send reports to a public mailing list. Therefore I propose to create another subscription moderated list just for these kinds of reports. I'm afraid it could be too noisy for security@commons. Proposal Unless anybody objects until then I will create such a list (I believe there is a self-service thingy for that, otherwise I'll ask the infra folks) on the coming Sunday. I'd add myself as a moderator but we will need more moderators. Also I'll gladly accept ideas for the name of the list. If there are objections against yet another mailing list I'll ask Fabian to set things up using a private mail alias. If you want to receive the messages as well, please tell me. Cheers Stefan [1] https://lists.apache.org/thread.html/rb34ea7d9272b8e600437ea705b13aba1bcc2f23ceb55880bce27e479%40%3Cdev.commons.apache.org%3E [2] https://google.github.io/oss-fuzz/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
Please don't use @security for automated emails, that ML IMO should be for humans. If you want to setup a new ML for bots that's fine, we can direct GitHub's Dependanot emails there if GitHub allows for that. Gary On Tue, Apr 13, 2021, 12:57 Mark Thomas wrote: > On 13/04/2021 17:49, Stefan Bodewig wrote: > > > > > Fabian has offered to set up OSS Fuzz for Compress. Given that the > > issues OSS Fuzz detects may or may not be security sensitive, I don't > > feel it would be a good idea to have the tool send reports to a public > > mailing list. Therefore I propose to create another subscription > > moderated list just for these kinds of reports. I'm afraid it could be > > too noisy for security@commons. > > Following the "split by audience, not by topic" guideline, I'd suggest > using security@commons.a.o rather than a separate list. Much, much > bigger projects than Compress use OSS Fuzz and direct traffic to their > security list where it seems to be manageable. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [all] OSS Fuzz
On 13/04/2021 17:49, Stefan Bodewig wrote: Fabian has offered to set up OSS Fuzz for Compress. Given that the issues OSS Fuzz detects may or may not be security sensitive, I don't feel it would be a good idea to have the tool send reports to a public mailing list. Therefore I propose to create another subscription moderated list just for these kinds of reports. I'm afraid it could be too noisy for security@commons. Following the "split by audience, not by topic" guideline, I'd suggest using security@commons.a.o rather than a separate list. Much, much bigger projects than Compress use OSS Fuzz and direct traffic to their security list where it seems to be manageable. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
