On Thu, May 28, 2020 at 08:09:15PM +0200, Michael Niedermayer wrote: > On Thu, May 28, 2020 at 01:43:17PM -0300, James Almer wrote: > > On 5/28/2020 1:20 PM, Michael Niedermayer wrote: > > > TODO: Bump > > > > > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > > > --- > > > doc/APIchanges | 3 +++ > > > doc/codecs.texi | 2 ++ > > > libavcodec/avcodec.h | 6 ++++++ > > > libavcodec/h264dec.c | 2 +- > > > libavcodec/options_table.h | 1 + > > > tools/target_dec_fuzzer.c | 2 +- > > > 6 files changed, 14 insertions(+), 2 deletions(-) > > > > > > diff --git a/doc/APIchanges b/doc/APIchanges > > > index fb5534b5f5..3e20a44379 100644 > > > --- a/doc/APIchanges > > > +++ b/doc/APIchanges > > > @@ -15,6 +15,9 @@ libavutil: 2017-10-21 > > > > > > API changes, most recent first: > > > > > > +2020-xx-xx - xxxxxxxxxx - lavc 58.xx.100 - avcodec.h > > > + Add AV_CODEC_FLAG2_FAST_UNSAFE > > > + > > > 2020-xx-xx - xxxxxxxxxx - lavc 58.88.100 - avcodec.h codec.h > > > Move AVCodec-related public API to new header codec.h. > > > > > > diff --git a/doc/codecs.texi b/doc/codecs.texi > > > index c092aadc0e..46790b66b3 100644 > > > --- a/doc/codecs.texi > > > +++ b/doc/codecs.texi > > > @@ -787,6 +787,8 @@ Possible values: > > > @table @samp > > > @item fast > > > Allow non spec compliant speedup tricks. > > > +@item fast_unsafe > > > +Allow speedup tricks which can lead to out of array reads and crashes on > > > damaged or crafted files. > > > > This will raise more than a couple eyebrows. Having an option to enable > > what people will consider security issues is not a good idea at all. For > > starters, it acknowledges lavc is not secure and has known issues that > > are purposely not being fixed. > > now, thats not what this was intended to do, of course. > the idea is more > > A user can have a stream that is known to be valid, quite possibly > the users own stream, or otherwise "in house" made or already checked > to be valid. > > In that case any code that is only needed for invalid streams becomes > unneeded. > > > > And on top of it, this can't be outright > > disabled/removed at compile time, so something could still call > > ffmpeg/lavc with it enabled. > > well, yes, but thats not the only such case > we have other options to enable unsafe behavior
Also if people dont want a "fast_unsafe" flag we surely can just drop this patch, and set the value to 0 where it otherwise would be used thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
