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

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 5579 bytes --]

On Mon, Jul 15, 2024 at 01:32:20PM +0200, Kacper Michajlow wrote:
> On Sun, 14 Jul 2024 at 21:55, 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
> 
> I respect your decision.

> However, saying that anyone's (or my)
> contribution doesn't benefit FFmpeg is a strange thing to say for an
> open source project maintainer.

And noone made such a statement. You are reading something thats not written
there


> 
> It's all about time. I don't get paid to do any of this, so
> duplicating issues/reports manually from one system to another, if
> they are already reported, is a monkey's job which I'm not willing to
> do.

ok
for reference i find no mail from you to ffmpeg-security
Is it correct you never reported any of the issues you talk about
neither new nor duplciate ?


> This time could be devoted to actually fixing the issues. I'd like
> to help, but if it is not required, I will focus on other things.

This is the first time i remember you offering to help.
Your request previosuly:

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

And to that my reply was a "no", iam not agreeing to give access to
someone who wants to mainly monitor upstream.

Also again id like to point out we do not have an issue with duplicate
reports ATM, so we would be fixing something that has not actually happened

Also if i fix an issue i post the corresponding patch to ffmpeg-devel
so the case you write about makes just no sense
if no patch is posted the issue is not fixed and any fix you would submit
would not be duplicated


> 
> It also doesn't help that trac.ffmpeg is a black hole, where only
> Balling seems to be reading those tickets. Frankly, the review process
> is not better, as even trivial fixes take months to merge.

Yes, we do need to improve this. Directing some funds to people
who did maintain trac in the past would solve this.
Let me speak blunt and clear here. I think carl should be paid to
maintain trac.
And the maintaince should switch to a system more similar to linux
its more scalable


> 
> > Also i expect the number of outstanding ossfuzz issues to decrease now
> > after the bulk of coverity issues has been dealt with
> 
> For some class of issues sure, but Coverity bigfixes are most of the
> time workarounding the static analysis limitations. Fuzzing is more
> powerful and analyzes the code as a whole, not small snippets of it.

You misunderstand.
I was doing most ossfuzz fixes, and recently i was switching between a month working
"fulltime" on coverity and then a month allocating that time to ossfuzz so
ossfuzz only got half of my attention and we have a month or so of unattended
issues (because i put the last month time in coverity)

thx

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".