It does sound like a good initiative, thanks for including us. I still have the concern that others have expressed below around exposing security issues. We have guidelines to follow and shouldn't be exposing them openly. I see that Tom said:
>> All open source and in moderate to wide use already. Only find sec >> bugs is security specific - Infer and Error Prone might find security >> bugs but they are more general purpose in nature. But I'm unsure about what this is saying. Otherwise, I'm good with bug bashing. -Flavio > On 28 Sep 2020, at 08:11, Enrico Olivelli <eolive...@gmail.com> wrote: > > Tom > Overall I think that we can move forward. > > This thread has been around for a while, there are no objections, every > question has been answered. > > Thank you very much > > I hope this activity will help in growing Zookeeper project both in code > quality and with more contributions, that is to help the community to grow. > > Best regards > > Enrico > > Il Lun 28 Set 2020, 01:27 Tom DuBuisson <to...@muse.dev> ha scritto: > >> Norbert, >> >> Yes, you understand that correctly. And those analyzers are FindSecBugs, >> Error Prone and Infer. All open source and in moderate to wide use >> already. Only find sec bugs is security specific - Infer and Error Prone >> might find security bugs but they are more general purpose in nature. >> >> -Tom >> >> On Sun, Sep 27, 2020 at 3:43 PM Norbert Kalmar >> <nkal...@cloudera.com.invalid> >> wrote: >> >>> Hello Tom, >>> >>> +1 on the initiative, thanks for bringing this to our attention. >>> >>> If I understand correctly, there will be no disclosed security issues >> which >>> cannot be found with open source static analyzers. >>> >>> Regards, >>> Norbert >>> >>> >>> On Sun, Sep 27, 2020 at 8:23 AM Szalay-Bekő Máté < >>> szalay.beko.m...@gmail.com> >>> wrote: >>> >>>> Hello Guys, >>>> >>>> In general I like the idea, but unfortunately I can not really >>> participate >>>> (either in the coding or in the review) as I have a few important >>> projects >>>> close to deadline at the moment. >>>> >>>> My only concern is with the security bugs, which I don't like to be >>> openly >>>> reported before publishing a release with the fix. But for any other >> kind >>>> of bugfixes / improvements, I am very positive with the initiative. >>>> >>>> >>>> Best regards, >>>> Mate >>>> >>>> On Sun, Sep 27, 2020, 07:06 Tom DuBuisson <to...@muse.dev> wrote: >>>> >>>>> Enrico et al, >>>>> >>>>> Are there other thoughts on this? It would be great to get setup >>> before >>>>> the bash actually begins. Enrico, lacking other voices would you >> like >>> to >>>>> make a final call? >>>>> >>>>> -Tom >>>>> >>>>> On Thu, Sep 24, 2020 at 3:30 AM Enrico Olivelli <eolive...@gmail.com >>> >>>>> wrote: >>>>> >>>>>> Tom, >>>>>> Personally I am +1 with this proposal. Thanks for your >>> clarifications. >>>>>> >>>>>> But we should ear opinions from other people in this list >>>>>> >>>>>> >>>>>> Enrico >>>>>> >>>>>> Il giorno mer 23 set 2020 alle ore 23:51 Tom DuBuisson < >>> to...@muse.dev >>>>> >>>>> ha >>>>>> scritto: >>>>>> >>>>>>> Enrico, >>>>>>> >>>>>>> On the topic security issues and reporting: Muse's default >>>>> configuration >>>>>>> is open source tools and here it is run on open source projects. >>> The >>>>>>> results are thus already available publicly (in this case from >> FSB, >>>>>> Infer, >>>>>>> and Error Prone). Muse doesn't post anything to GitHub except in >>> the >>>>>> case >>>>>>> of pull requests and then only if the bug is deemed to have been >>>>>>> "introduced" as part of the PR - meaning it shouldn't be a >>>>> vulnerability >>>>>> in >>>>>>> currently shipped software. >>>>>>> >>>>>>> If there are desires or proposals about more control over bug >>> reports >>>>> in >>>>>> a >>>>>>> convenient, configurable, manner then we'd really like to dig in >>> and >>>>> hear >>>>>>> how to help. In case there is more discussion on this point I'm >>>> CCing >>>>>>> Andrew who leads Muse's product design. >>>>>>> >>>>>>> -Tom >>>>>>> >>>>>>> On Wed, Sep 23, 2020 at 1:09 PM Enrico Olivelli < >>> eolive...@gmail.com >>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Il Mer 23 Set 2020, 19:02 Tom DuBuisson <to...@muse.dev> ha >>>> scritto: >>>>>>>> >>>>>>>>> Enrico, >>>>>>>>> >>>>>>>>> The Muse App requires two main abilities. First is events, >>> such >>>> as >>>>>>>>> notification when pull requests are opened or updated. >> Second >>> is >>>>>>>>> permission to post comments (which is always possible for >>> humans >>>>> but >>>>>>> more >>>>>>>>> tightly controlled when the poster authenticates as a github >>>>>>>> application). >>>>>>>>> The repository being public has allowed us to run the app and >>>>> observe >>>>>>>>> ErrorProne, Infer, and FindSecBugs all run out of the box and >>>>> without >>>>>>>>> custom configuration. >>>>>>>>> >>>>>>>> >>>>>>>> Makes sense. >>>>>>>> >>>>>>>> One last question from my side >>>>>>>> What about security issues? >>>>>>>> Our policy is to have them reported to >>>> secur...@zookeeper.apache.org >>>>>>>> before >>>>>>>> public disclosure >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Enrico >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Tom >>>>>>>>> >>>>>>>>> On Wed, Sep 23, 2020 at 6:35 AM Enrico Olivelli < >>>>> eolive...@gmail.com >>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Il Mer 23 Set 2020, 00:44 Tom DuBuisson <to...@muse.dev> >> ha >>>>>> scritto: >>>>>>>>>> >>>>>>>>>>> Zookeeper Developers, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As part of our sponsorship of ApacheCon, our company >>> MuseDev >>>> is >>>>>>>> doing a >>>>>>>>>> Bug >>>>>>>>>>> Bash for select Apache projects. We'll bring members of >> the >>>>>>> ApacheCon >>>>>>>>>>> community together to find and fix a range of security >> and >>>>>>>> performance >>>>>>>>>> bugs >>>>>>>>>>> during the conference, and gameify the experience with >>>> teams, a >>>>>>>>>>> leaderboard, and prizes. The bash is open to everyone >>> whether >>>>>>>> attending >>>>>>>>>> the >>>>>>>>>>> conference or not, and our whole dev team will also be >>>>>>> participating >>>>>>>> to >>>>>>>>>>> help fix as many bugs as we can. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We're seeding the bug list with results from Muse, our >> code >>>>>>> analysis >>>>>>>>>>> platform, which runs as a Github App and comments on >>> possible >>>>>> bugs >>>>>>> as >>>>>>>>>> part >>>>>>>>>>> of the pull request workflow. Here's an example of what >> it >>>>> looks >>>>>>>> like: >>>>>>>>>>> >>>>>>>>>>> >>>>> https://github.com/curl/curl/pull/5971#discussion_r490252196 >>>>>>>>>>> <https://github.com/curl/curl/pull/5971> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We explored a number of Apache projects and are reaching >>> out >>>>>>> because >>>>>>>>> our >>>>>>>>>>> analysis through Muse found some interesting bugs that >>> could >>>> be >>>>>>> fixed >>>>>>>>>>> during the Bash. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We're writing to see if you'd be interested in having >> your >>>>>> project >>>>>>>>>> included >>>>>>>>>>> in the Bash. Everything is set up on our end, and if >> you're >>>>>>>> interested, >>>>>>>>>> we >>>>>>>>>>> would need you to say yes on this listserv, and we’ll >> work >>>> with >>>>>> the >>>>>>>>>> Apache >>>>>>>>>>> Infrastructure team to grant Muse access to your Github >>>> mirror. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It is a public repo, which kind of access does it need? >>>>>>>>>> >>>>>>>>>> Enrico >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We'll then >>>>>>>>>>> make sure it's all set-up and ready for the Bash. And of >>>>> course, >>>>>>>>> everyone >>>>>>>>>>> on the project is most welcome to join the Bash and help >> us >>>>> smash >>>>>>>> some >>>>>>>>>>> bugs. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Tom >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
