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

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

[Kacper Michajlow]

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.

Thanks,
Kacper

diff --git a/projects/ffmpeg/project.yaml b/projects/ffmpeg/project.yaml
index fe510402f..7aba17cc5 100644
--- a/projects/ffmpeg/project.yaml
+++ b/projects/ffmpeg/project.yaml
@@ -12,6 +12,10 @@ auto_ccs:
- "twsmith@mozilla.com"
- "kempfjb@gmail.com"
- "jordyzomer@google.com"
+sanitizers:
+ - address
+ - memory
+ - undefined
fuzzing_engines:
- afl
- honggfuzz
_______________________________________________
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".

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

[Michael Niedermayer]

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

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

If msan has been tested and if it works and the whole behaves sanely,
it should obviously be enabled

thx

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

It is a danger to trust the dream we wish for rather than
the science we have, -- Dr. Kenneth Brown

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

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

[Kacper Michajlow]

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

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

[Kacper Michajlow]

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.

- Kacper
_______________________________________________
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".

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

[Michael Niedermayer]

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

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

Also i expect the number of outstanding ossfuzz issues to decrease now
after the bulk of coverity issues has been dealt with

thx

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

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."

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

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

[Kacper Michajlow]

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.

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

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.

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

- Kacper
_______________________________________________
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".

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

[Vittorio Giovara]

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.

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.
-- 
Vittorio
_______________________________________________
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".

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

[epirat07]

On 14 Jul 2024, at 21:55, Michael Niedermayer 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

This seems quite rude… Maybe you did not intend it but thats how
it reads to me…

>
> Also i expect the number of outstanding ossfuzz issues to decrease now
> after the bulk of coverity issues has been dealt with
>
> thx
>
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 1
> "Used only once"    - "Some unspecified defect prevented a second use"
> "In good condition" - "Can be repaird by experienced expert"
> "As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
> _______________________________________________
> 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".
_______________________________________________
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".

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

[Michael Niedermayer]

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

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

[Michael Niedermayer]

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

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

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

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

[Andrew Sayers]

On Tue, Jul 16, 2024 at 02:25:04PM +0200, Michael Niedermayer wrote:
> On Mon, Jul 15, 2024 at 02:36:15PM +0200, Vittorio Giovara wrote:
> > 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 ...)
>     ;)

A little off-topic, but I suspect this points to a deeper problem:

When a new person comes along and says "can I contribute my way?", replying
"no, here's the correct way to do it" leaves them with two options:
accept things are done that way for reasons they don't understand,
or go find another project that does things the way they already understand.

If you want more maintainers - that is, people with a deep understanding of the
project - you need to engage new contributors in a discussion about why things
are done that way.  Then over the course of years, they'll learn enough to
become maintainers.

I realise this can be daunting, but think about it this way: if you're right
about the best solution to some problem, arguing your case is a great way to
weed out illogical people who shouldn't become maintainers.  And if you're
wrong, you can hand over a part of the project to a new maintainer, safe in the
knowledge they understand that particular issue better than you.
_______________________________________________
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".

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

[Vittorio Giovara]

On Tue, Jul 16, 2024 at 2:25 PM Michael Niedermayer <michael@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@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 ?
>

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

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

[Kacper Michajlow]

On Tue, 16 Jul 2024 at 14:14, Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> 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 ?

Correct, I was sending the patches for the issues instead. All related
to our fuzzing results. Maybe nothing significant, but...

https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240317023628.1936-1-kasper93@gmail.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240509140211.1296-1-kasper93@gmail.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240510014931.644-1-kasper93@gmail.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240510020756.1135-1-kasper93@gmail.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240511104717.231-1-kasper93@gmail.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240602013818.1047-1-kasper93@gmail.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240602121448.1069-1-kasper93@gmail.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240625215030.321-1-kasper93@gmail.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240626184440.1318-1-kasper93@gmail.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240627004037.1336-1-kasper93@gmail.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240627004037.1336-2-kasper93@gmail.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240627004037.1336-3-kasper93@gmail.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240627004037.1336-4-kasper93@gmail.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240710152401.1192-1-kasper93@gmail.com/

and patch for ossfuzz itself https://github.com/google/oss-fuzz/pull/12211

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

Not everythings revolves around "you". I was trying to improve the
process we could apply to make fixing those issues more streamlined
for both of us. If the issue is found/reported upstream, this is
totally wasted time for me to create and send a report to you about it
and for you it is wasted time to read this report, while you could
already see the issue or be fixing something else.

Either way this is very minor process optimization and a way for me to
be able to contribute more. See like I said, I will not copy/paste
manually all reports, this is just not something I see like a good
investment of my time. But reporting or fixing things that your
fuzzing doesn't cover, is on the other hand interesting to me.

Like I said, I respect your decision and that's over. No need to dvele
more on it. I was just initially surprised by gatekeeping, after all
ossfuzz is an external service provided to you for free and I wouldn't
take it from you :)

- Kacper
_______________________________________________
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".

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

[Anton Khirnov]

Quoting Michael Niedermayer (2024-07-16 14:14:34)
> > > > 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.

What do you think gives you the right to make such decisions on your
own?

-- 
Anton Khirnov
_______________________________________________
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".

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

[Nicolas George]

Anton Khirnov (12024-07-17):
> What do you think gives you the right to make such decisions on your
> own?

Despite what some people might think, including on occasion himself,
Michael is still our project leader, appointed by our founder and
embodying its spirit of freedom and experimentation. It is not something
one can resign from, and even less something one can be expelled from.

-- 
  Nicolas George
_______________________________________________
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".

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

[Vittorio Giovara]

On Wed, Jul 17, 2024 at 2:22 PM Nicolas George <george@nsup.org> wrote:

> Anton Khirnov (12024-07-17):
> > What do you think gives you the right to make such decisions on your
> > own?
>
> Despite what some people might think, including on occasion himself,
> Michael is still our project leader, appointed by our founder and
> embodying its spirit of freedom and experimentation. It is not something
> one can resign from, and even less something one can be expelled from.
>

He is not. Stop spreading propaganda or further emails will be forwarded to
CC for disciplinary action.
-- 
Vittorio
_______________________________________________
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".

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

[Nicolas George]

Vittorio Giovara (12024-07-17):
> He is not. Stop spreading propaganda or further emails will be forwarded to
> CC for disciplinary action.

Can you quote the article of the code of conduct that you pretend I am
violating?

This use of intimidation to silence discourse that one does not like is…
concerning.

-- 
  Nicolas George
_______________________________________________
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".

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

[Vittorio Giovara]

On Wed, Jul 17, 2024 at 2:40 PM Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (12024-07-17):
> > He is not. Stop spreading propaganda or further emails will be forwarded
> to
> > CC for disciplinary action.
>
> Can you quote the article of the code of conduct that you pretend I am
> violating?
>
> This use of intimidation to silence discourse that one does not like is…
> concerning.
>

This is not intimation, it has been brought up *multiple times* how your
insistence of spreading misinformation and propaganda on the project has
caused grief and is incoherent with the reality of the project.
Establishing a process where there is not is a fundamental step for the
benefit of the community, and while no one is asking you to actively
collaborate, it was explicitly requested that you stop this bickering
https://ffmpeg.org//pipermail/ffmpeg-devel/2024-April/325823.html (see the
us-vs-others clause).

You are welcome to fund the Church of FFmpeg with Micheal as leader, who
will attend remotely, no video, but this is FFmpeg the community project,
managed by the community, and nobody else.
-- 
Vittorio
_______________________________________________
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".