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@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@gmail.com>
> > wrote:
> > > >
> > > > On Thu, 27 Jun 2024 at 00:45, Michael Niedermayer
> > > > <michael@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 ?

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 ...)
    ;)


> 
> 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.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact