[FFmpeg-devel] [PATCH 1/2] Avoid using the term "file" and prefer "url" in some docs and comments

[wm4]

On Fri, 9 Dec 2016 14:33:08 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Fri, Dec 09, 2016 at 09:55:52AM +0100, wm4 wrote:
> > On Fri, 9 Dec 2016 03:48:39 +0100
> > Michael Niedermayer <michael at niedermayer.cc> wrote:
> >   
> > > On Thu, Dec 08, 2016 at 11:13:16AM -0900, Lou Logan wrote:  
> > > > On Mon,  5 Dec 2016 13:52:50 +0100, Michael Niedermayer wrote:
> > > >     
> > > > > This should make it less ambigous that these are URLs
> > > > > 
> > > > > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> > > > > ---
> > > > >  doc/ffmpeg.texi  | 18 +++++++++---------
> > > > >  doc/ffplay.texi  |  6 +++---
> > > > >  doc/ffprobe.texi | 10 +++++-----
> > > > >  ffmpeg_opt.c     |  4 ++--
> > > > >  4 files changed, 19 insertions(+), 19 deletions(-)    
> > > > 
> > > > Although this is a trivial patch, approximately 7 hours between sending
> > > > a patch and applying without feedback isn't enough time. At least 24
> > > > hours would be preferrable.    
> > > 
> > > there were open and fully public security bugs, the use of untrusted
> > > filenames which look like urls aka files as in
> > > "http://someserver.com"
> > > would allow potential remote code execution  
> >   
> 
> > I guess "security bugs" now justify any kind of change?  
> 
> what exactly is this comment supposed to mean ?

I'm just saying that security fixes doesn't mean that quality control
should be lacking. Maybe rather the opposite.

> 
> > 
> > It's clear that a user has to prefix filenames with file: or so, since
> > it will interpret various strings as not-files (like as an option or an
> > URL). Thus it's not a security bug, just an user error.  
> 
> There are really just 2 options, either its safe to use arbitrary
> filenames in the arguments, or it has to be documented that these are
> not arbitrary filenames, aka its not safe to put arbitrary things in
> there.

Yes. If you allow "plain" local fileanes, it's inherently ambiguous.
Maybe we could go as far as disallowing such filenames by default, and
requiring that the filename starts with "/", "./" or "file:".

I also claimed that a filename can be misinterpreted as option - but
that's probably not the case: filenames for input always are passed to
"-i" or similar options. Only output filenames are implicit.

Anyway, I might have assumed that this discussion is about patch 2/2,
not 1/2.

> And it certainly was not clear enough as tickets are being opened on
> the assumtation that this was safe and that by security researchers
> 
> 
> 
> [...]