[FFmpeg-devel] [OSS-Fuzz] Have you considered enabling memory sanitizer?

[Vittorio Giovara]

On Tue, Jul 16, 2024 at 2:25 PM Michael Niedermayer <michael at niedermayer.cc>
wrote:

> On Mon, Jul 15, 2024 at 02:36:15PM +0200, Vittorio Giovara wrote:
> > On Sun, Jul 14, 2024 at 9:55 PM Michael Niedermayer <
> michael at niedermayer.cc>
> > wrote:
> >
> > > On Sat, Jul 13, 2024 at 11:12:40PM +0200, Kacper Michajlow wrote:
> > > > On Thu, 27 Jun 2024 at 02:50, Kacper Michajlow <kasper93 at gmail.com>
> > > wrote:
> > > > >
> > > > > On Thu, 27 Jun 2024 at 00:45, Michael Niedermayer
> > > > > <michael at niedermayer.cc> wrote:
> > > > > >
> > > > > > On Wed, Jun 26, 2024 at 09:07:42PM +0200, Kacper Michajlow wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Like in the topic. I think it would be useful to enable MSAN on
> > > > > > > OSS-Fuzz. We get some tiny issues and it would be probably
> good to
> > > > > > > have them tracked upstream. All infra is here, so enabling it
> is as
> > > > > > > simple as adding it to the project.yaml. Except libbz2.so and
> > > libz.so
> > > > > > > would have to be built inline instead, looking at the build.sh,
> > > they
> > > > > > > are prebuilt. The rest should just work (TM), but needs to be
> > > tested.
> > > > > > > You can set an "experimental' flag to have it not create
> issues on
> > > > > > > monorail, initially.
> > > > > >
> > > > > > I assumed ossfuzz would enable all sanitizers by default
> > > > >
> > > > > They do not do that by default, because MSAN requires all
> dependencies
> > > > > to be instrumented too. See
> > > > >
> > >
> https://google.github.io/oss-fuzz/getting-started/new-project-guide/#sanitizers
> > > > >
> > > > > Looking at build.sh for ffmpeg, it should be fine to enable it.
> > > > > Obviously I have not tested everything, but I was running some
> tests
> > > > > locally with MSAN and also tested it with mpv oss-fuzz builds
> where we
> > > > > build ffmpeg too with MSAN.
> > > > >
> > > > > - Kacper
> > > >
> > > > I've sent a PR to enable MSAN and a few other build improvements.
> > > > Please take a look https://github.com/google/oss-fuzz/pull/12211
> > > >
> > >
> > > > Also, would it be ok to add myself to auto_ccs for ffmpeg? Mostly to
> > > > monitor what issues are reported upstream, as we get some reports in
> > > > mpv fuzzing and I never know if I should report it upstream (ffmpeg)
> > > > or it is already found by first-party fuzzing and I shouldn't make
> > > > more noise.
> > >
> > > you are welcome to submit bug reports, you are welcome to submit bug
> fixes
> > > if you find issues in FFmpeg.
> > >
> > > If someones work in FFmpeg or rather FFmpeg benefits from someone
> having
> > > access to the reports, then (s)he should receive access. This seems not
> > > to apply here
> > >
> >
> > Disagree - this is not the right way to attract new contributors.
>
> no ?
> did you do a study ?
>

I didn't but I've been to enough open source conferences that I picked up a
few things on community fostering.
When was the last time you attended one?


> try this:
> A. "please we need more maintainers" (we tried this i think)
> B. gently push someone away
>     (now people are angry, they want their rights, their access, they want
> to
>      contribute ...)
>     ;)
>

C. let's give the tools maintainers need, like gitlab/gitea/whatever, and
accept reasonable security contributions

at least let's define a process to grant people access when requested

> Also i expect the number of outstanding ossfuzz issues to decrease now
> > > after the bulk of coverity issues has been dealt with
> > >
> >
> > The majority of coverity issues are false positives, I fail to see the
> > relationship here.
>
> I do both coverity and ossfuzz work, and while i have done significantly
> more
> in the last months than i did last year, i still have falling a bit behind
> with
> ossfuzz fixing.
>

So what's the problem with having an extra pair of helping hands?
-- 
Vittorio