[FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it

[Michael Niedermayer]

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 <michael at 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.
> > > + at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200528/74ef7ab9/attachment.sig>