[FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[compn]

On Sun, 2 Oct 2016 23:16:02 +0200
u-h8zb at aetey.se wrote:

> > looking at the code? Seriously?)
> 
> Yes, I am serious.

vp3 is a decoder written 10+ years ago by a dev who is no longer
active in ffmpeg.

we have many decoders and encoders (and other code) in ffmpeg that have
not been audited (to my knowledge).

i know this isnt an excuse for not looking at the code. just letting
you know the history.

> Frankly, your tone looks unpleasant.
> It is a friendly information to make you aware. I guess you were not.

please dont think carl's tone is unpleasant, maybe he is just
incredulous.

carl has tested and verified thousands of bugs for ffmpeg. carl also
fixes some of them. carl i think was confused by your comment, because
carl would like to reproduce the bug. reproducing the bug with an easy
command line, on a dev computer usually makes the bug finding and fixing
quicker.

> To give you an example of successful code auditing, the corresponding
> UB-problem in libtheora was properly fixed without anybody at Xiph
> having to install musl.
> That's why I still believe that auditing the code is more useful than
> hunting once again the hard-to-pinpoint symptoms of the already known
> cause.

do you have any suggestions for how the ffmpeg project could do
successful code audits?

we have static code analyzers like coverity running on ffmpeg. there
has also been a lot of fuzz testing done. i'm sure some of the more
popular decoders like h264 have had code audits done in private.

i really dont see much enthusiasm for line by line code auditing within
ffmpeg. in fact, i'd say people would rather re-write an entirely new
piece of code than try to clean up the old code. this isnt a knock on
anyone or any piece of code, just my observation.

feel free to tell me that i am wrong.

-compn