[FFmpeg-devel] [PATCH 1/2] Avoid using the term "file" and prefer "url" in some docs and comments
nfxjfg at googlemail.com
Fri Dec 9 19:42:54 EET 2016
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
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,
> And it certainly was not clear enough as tickets are being opened on
> the assumtation that this was safe and that by security researchers
More information about the ffmpeg-devel