On Fri, 9 Dec 2016 14:33:08 +0100 Michael Niedermayer <mich...@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 <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? > > 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 > > > > [...] _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel