On Fri, 9 Dec 2016 03:48:39 +0100 Michael Niedermayer <mich...@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 <mich...@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? 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. > i applied this quickly as it seemed important to me to clarify that > the command line arguments are not just normal file names > in addition to fixing the bug which depended on such files > > can you help me clarify and improve this further ? > I suspect you can reword this quicker yourself than with me messing > around further > > The really important point is that one cannot saftely put a random > untrusted string or filename in place of these arguments. > untrusted filenames needs "file:" prefix at least > > Thanks and sorry for havning applied this so quickly > > [...] > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel