[FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

Michael Niedermayer michael at niedermayer.cc
Wed Jan 27 14:04:06 CET 2016

On Sun, Jan 24, 2016 at 07:39:18PM +0100, Nicolas George wrote:
> Le quintidi 5 pluviôse, an CCXXIV, Michael Niedermayer a écrit :
> > the argument is added, not out of strict need, (there already is a
> > AVDictionary that can be used) but to make it clear that the author
> > set the whitelist correctly. Also it simplifies the code compared
> > to using the AVDictionary.
> > 
> > security relevant code should be clear and explicit so that a
> > mistake in the code can easily be spotted. Its very hard to spot that
> > a passed dictionary doesnt carry/lost the whitelist, easy to spot that
> > a argument is missed and set to NULL
> I see the point, but since this whitelist is not a full fix, I believe this
> is premature.

The whitelist allows the user to limit the set of protocols that can
be used. Thats a feature that it exactly implements. It doesnt do more
it doesnt do less.


> > another problem of the struct is that depending on from which lib
> > the protocols are set the same protocol may have unequal pointers
> > 
> > which system do people prefer ?
> > do we have a volunteer to implement a struct based system ?
> > 
> > do people want the string based solution to be applied till then
> > or to not have this security feature until then ?
> Do we want a good fix, or do we want a quick fix? As I explained earlier, a
> good fix requires designing a real security policy, not just a stupid
> whitelist. It will take time.

a fix, good or not that isnt implemented is useless

I am not really attracted to the design you suggest, to me its worse
in several ways but above all its alot more work. So I dont volunteer
to implement that. Thats not meant as a objection to it if someone
does implement it and people prefer it. (and it works with the same
or a supreset of features)

ill post a updated patch with the string whitelists, as that is
all already existing code and not much work to improve

if people dont like the implementation iam happy to drop it and move
on and work on other stuff, my todo list is long enough ...


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160127/c9374c93/attachment.sig>

More information about the ffmpeg-devel mailing list