[FFmpeg-devel] [PATCH 3/9] lavf/file: implement EXCL flag.

[wm4]

On Sat, 19 Apr 2014 15:32:27 +0200
Nicolas George <george at nsup.org> wrote:

> Le decadi 30 germinal, an CCXXII, wm4 a écrit :
> > Uh, that sounds severely misdirected. You shouldn't use any relative
> > paths for extracting such attachments, and trying to make sure no files
> 
> I do not intend to use any specific kind of paths, just the one provided by
> the metadata.

Metadata is input data. You should not rely on the assumption that
input data is well-behaved.

> > get overwritten during extraction just seems like a very weak way to
> > limit the potential damage such a very unsafe mechanism could cause. I
> > don't think it's very secure if an attacker can create arbitrary files
> > on your filesystem, even if it can't _overwrite_ existing files.
> 
> Apparently, you missed the part where I said the documentation would contain
> visible warnings about that.

You should avoid unsafe things whenever possible. I'm not sure if
documentation is good enough for this, because you would have to
inspect the file manually every time you run this command on it. It's
not safe for scripting. It's a bad BAD BAD idea.

> > Why extract all attachments at once? What's the possible use case (I
> > see none)?
> 
> Inserting the fonts into the fontconfig system, lowering the loading time,
> would be one obvious example. Doing batch processing, such as format
> conversion, on the attachments, would be another example.

The first example sounds pretty broken. Fonts found in MKV are usually
broken, so installing these fonts by extracting them to the local
fontconfig fonts directory will break your system. Besides, libass (the
only portable ASS renderer) can use fontconfig in a safer way, and
recently a patch was added to make vf_subtitles respect embedded fonts.

The second example... as I said, it's not safe to run from a script.
Besides, how would the processing script find the extracted files, if
they can be spread all over the filesystem?

> >	     You could just extract individual attachments, reporting
> > their name in ffprobe and making the user provide a destination
> > filename, like mkvextract does.
> 
> I could decode H.264 with a pen, a lot of paper and a pocket calculator;
> darn, people used to compute planets' orbits without even the pocket
> calculator. Extracting all the attachments in a file with a tool that works
> one by one is nowhere as tedious, but it is still plenty tedious enough. And
> I find it tedious while I am quite fluent in shell, which means I can gain a
> lot of time.

Then find a safe way to do it.

> >				  In fact, why not just leave this to
> > mkvextract?
> 
> And let us leave video decoding to dshow...

That's pretty trollish. mkvextract is safe for scripting and is
portable to all platforms. But I guess you must reinvent the wheel...

> Regards,
>