Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
* [FFmpeg-devel] [PATCH 1/2] lavu: add syntax for loading AV_OPT_TYPE_BINARY from files
@ 2022-03-04 15:03 Niklas Haas
  2022-03-04 15:03 ` [FFmpeg-devel] [PATCH 2/2] lavu/tests/opts: add tests for filepath options Niklas Haas
  2022-03-08 11:48 ` [FFmpeg-devel] [PATCH 1/2] lavu: add syntax for loading AV_OPT_TYPE_BINARY from files Anton Khirnov
  0 siblings, 2 replies; 7+ messages in thread
From: Niklas Haas @ 2022-03-04 15:03 UTC (permalink / raw)
  To: ffmpeg-devel; +Cc: Niklas Haas

From: Niklas Haas <git@haasn.dev>

I arbitrarily decided to use the syntax 'opt=@filename' to match e.g.
`curl -Ffield=@filename`, and also because @ is not a valid hex
character, nor does it conflict with any other common shell or ffmpeg
syntax.

This is arguably somewhat clunky because it does not round-trip with
av_opt_get - you will get back a hex interpretation of the loaded file,
rather than the filename it was loaded from. It also implies a (perhaps
unnecessary) memcpy from mapped file memory into a allocated memory.
This is unfortunately necessary because there's no way for us to know
whether av_free or av_file_unmap is needed to clean up previous option
values.

The motivating use case was the introduction of several new binary
options for vf_libplacebo, but other filters that currently rely on
manual file-path loading could benefit from it as well.
---
 doc/APIchanges      |  4 ++++
 libavutil/opt.c     | 53 ++++++++++++++++++++++++++++++++++++++++++++-
 libavutil/opt.h     |  5 +++++
 libavutil/version.h |  2 +-
 4 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index ea402f6118..0400b10721 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,10 @@ libavutil:     2021-04-27
 
 API changes, most recent first:
 
+2022-03-04 - xxxxxxxxxx - lavu 57.23.100 - opt.h
+  Add av_opt_set_filepath() to set a binary option from a file.
+  Support '@filename' syntax in av_opt_set() for binary options.
+
 2022-02-07 - xxxxxxxxxx - lavu 57.21.100 - fifo.h
   Deprecate AVFifoBuffer and the API around it, namely av_fifo_alloc(),
   av_fifo_alloc_array(), av_fifo_free(), av_fifo_freep(), av_fifo_reset(),
diff --git a/libavutil/opt.c b/libavutil/opt.c
index d951edca9d..151536d229 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -32,6 +32,7 @@
 #include "common.h"
 #include "dict.h"
 #include "eval.h"
+#include "file.h"
 #include "log.h"
 #include "parseutils.h"
 #include "pixdesc.h"
@@ -465,6 +466,33 @@ static int set_string_dict(void *obj, const AVOption *o, const char *val, uint8_
     return 0;
 }
 
+static int set_string_filepath(void *obj, const AVOption *o, const char *path, uint8_t **dst)
+{
+    int *lendst = (int *)(dst + 1);
+    uint8_t *bin;
+    size_t bin_len;
+    int err;
+
+    av_freep(dst);
+    *lendst = 0;
+
+    if (!path || !path[0])
+        return 0;
+
+    err = av_file_map(path, &bin, &bin_len, 0, obj);
+    if (err)
+        return err;
+
+    *dst = av_memdup(bin, bin_len);
+    av_file_unmap(bin, bin_len);
+
+    if (!*dst)
+        return AVERROR(ENOMEM);
+
+    *lendst = bin_len;
+    return 0;
+}
+
 int av_opt_set(void *obj, const char *name, const char *val, int search_flags)
 {
     int ret = 0;
@@ -492,7 +520,11 @@ int av_opt_set(void *obj, const char *name, const char *val, int search_flags)
     case AV_OPT_TYPE_STRING:
         return set_string(obj, o, val, dst);
     case AV_OPT_TYPE_BINARY:
-        return set_string_binary(obj, o, val, dst);
+        if (val && val[0] == '@') {
+            return set_string_filepath(obj, o, &val[1], dst);
+        } else {
+            return set_string_binary(obj, o, val, dst);
+        }
     case AV_OPT_TYPE_FLAGS:
     case AV_OPT_TYPE_INT:
     case AV_OPT_TYPE_INT64:
@@ -631,6 +663,25 @@ int av_opt_set_bin(void *obj, const char *name, const uint8_t *val, int len, int
     return 0;
 }
 
+int av_opt_set_filepath(void *obj, const char *name, const char *path, int search_flags)
+{
+    uint8_t *bin;
+    size_t bin_len;
+    int err;
+
+    if (!path || !path[0])
+        return av_opt_set_bin(obj, name, NULL, 0, search_flags);
+
+    err = av_file_map(path, &bin, &bin_len, 0, obj);
+    if (err)
+        return err;
+
+    err = av_opt_set_bin(obj, name, bin, bin_len, search_flags);
+    av_file_unmap(bin, bin_len);
+
+    return err;
+}
+
 int av_opt_set_image_size(void *obj, const char *name, int w, int h, int search_flags)
 {
     void *target_obj;
diff --git a/libavutil/opt.h b/libavutil/opt.h
index 2820435eec..97d7c69482 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -699,6 +699,11 @@ int av_opt_set_channel_layout(void *obj, const char *name, int64_t ch_layout, in
  * caller still owns val is and responsible for freeing it.
  */
 int av_opt_set_dict_val(void *obj, const char *name, const AVDictionary *val, int search_flags);
+/**
+ * @note This behaves like av_opt_set_bin() but loads the binary data from a
+ * file. May also return errors related to file I/O.
+ */
+int av_opt_set_filepath(void *obj, const char *name, const char *val, int search_flags);
 
 /**
  * Set a binary option to an integer list.
diff --git a/libavutil/version.h b/libavutil/version.h
index c7004601c8..6c5d90507c 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  57
-#define LIBAVUTIL_VERSION_MINOR  22
+#define LIBAVUTIL_VERSION_MINOR  23
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.35.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [FFmpeg-devel] [PATCH 2/2] lavu/tests/opts: add tests for filepath options
  2022-03-04 15:03 [FFmpeg-devel] [PATCH 1/2] lavu: add syntax for loading AV_OPT_TYPE_BINARY from files Niklas Haas
@ 2022-03-04 15:03 ` Niklas Haas
  2022-03-05 19:16   ` Michael Niedermayer
  2022-03-08 11:48 ` [FFmpeg-devel] [PATCH 1/2] lavu: add syntax for loading AV_OPT_TYPE_BINARY from files Anton Khirnov
  1 sibling, 1 reply; 7+ messages in thread
From: Niklas Haas @ 2022-03-04 15:03 UTC (permalink / raw)
  To: ffmpeg-devel; +Cc: Niklas Haas

From: Niklas Haas <git@haasn.dev>

Using the venerable HEADER.txt as a small file to load.
---
 libavutil/tests/opt.c    | 38 +++++++++++++++++++++++++++++++++++++-
 tests/fate/libavutil.mak |  2 +-
 tests/ref/fate/opt       |  4 ++++
 3 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/libavutil/tests/opt.c b/libavutil/tests/opt.c
index e6ea892373..e3d4edee4e 100644
--- a/libavutil/tests/opt.c
+++ b/libavutil/tests/opt.c
@@ -113,7 +113,7 @@ static void log_callback_help(void *ptr, int level, const char *fmt, va_list vl)
     vfprintf(stdout, fmt, vl);
 }
 
-int main(void)
+int main(int argc, const char **argv)
 {
     int i;
 
@@ -355,5 +355,41 @@ int main(void)
         av_opt_free(&test_ctx);
     }
 
+    printf("\nTesting av_opt_set_filepath()\n");
+    {
+        TestContext test_ctx = { 0 };
+        const char *samples;
+        char buf[256];
+        uint8_t *value;
+        int ret = AVERROR_BUG;
+
+        if (argc < 2)
+            return 1;
+        samples = argv[1];
+
+        test_ctx.class = &test_class;
+        av_opt_set_defaults(&test_ctx);
+        av_log_set_level(AV_LOG_QUIET);
+
+        if (snprintf(buf, sizeof(buf), "@%s/HEADER.txt", samples) >= sizeof(buf))
+            return 1;
+
+        ret = av_opt_set_filepath(&test_ctx, "bin", &buf[1], 0);
+        if (!ret)
+            ret = av_opt_get(&test_ctx, "bin", 0, &value);
+        printf("av_opt_set_filepath: bin='%s'\n",
+               ret ? av_err2str(ret) : (char *) value);
+        av_free(value);
+
+        ret = av_opt_set(&test_ctx, "bin", buf, 0);
+        if (!ret)
+            ret = av_opt_get(&test_ctx, "bin", 0, &value);
+        printf("av_opt_set: bin='%s'\n",
+               ret ? av_err2str(ret) : (char *) value);
+        av_free(value);
+
+        av_opt_free(&test_ctx);
+    }
+
     return 0;
 }
diff --git a/tests/fate/libavutil.mak b/tests/fate/libavutil.mak
index 1ec9ed00ad..587aa810cd 100644
--- a/tests/fate/libavutil.mak
+++ b/tests/fate/libavutil.mak
@@ -164,7 +164,7 @@ fate-tea: CMD = run libavutil/tests/tea$(EXESUF)
 
 FATE_LIBAVUTIL += fate-opt
 fate-opt: libavutil/tests/opt$(EXESUF)
-fate-opt: CMD = run libavutil/tests/opt$(EXESUF)
+fate-opt: CMD = run libavutil/tests/opt$(EXESUF) $(TARGET_SAMPLES)
 
 FATE_LIBAVUTIL += $(FATE_LIBAVUTIL-yes)
 FATE-$(CONFIG_AVUTIL) += $(FATE_LIBAVUTIL)
diff --git a/tests/ref/fate/opt b/tests/ref/fate/opt
index aac3fa0e7e..341693d097 100644
--- a/tests/ref/fate/opt
+++ b/tests/ref/fate/opt
@@ -417,3 +417,7 @@ Setting options string 'a_very_long_option_name_that_will_need_to_be_ellipsized_
 Setting 'a_very_long_option_name_that_will_need_to_be_ellipsized_around_here' to value '42'
 Option 'a_very_long_option_name_that_will_need_to_be_ellipsized_around_here' not found
 Error 'a_very_long_option_name_that_will_need_to_be_ellipsized_around_here=42'
+
+Testing av_opt_set_filepath()
+av_opt_set_filepath: bin='46415445202D2046466D706567204175746F6D617465642054657374696E6720456E7669726F6E6D656E740A687474703A2F2F666174652E6D756C74696D656469612E63782F0A0A'
+av_opt_set: bin='46415445202D2046466D706567204175746F6D617465642054657374696E6720456E7669726F6E6D656E740A687474703A2F2F666174652E6D756C74696D656469612E63782F0A0A'
-- 
2.35.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [FFmpeg-devel] [PATCH 2/2] lavu/tests/opts: add tests for filepath options
  2022-03-04 15:03 ` [FFmpeg-devel] [PATCH 2/2] lavu/tests/opts: add tests for filepath options Niklas Haas
@ 2022-03-05 19:16   ` Michael Niedermayer
  2022-03-08  7:47     ` J. Dekker
  0 siblings, 1 reply; 7+ messages in thread
From: Michael Niedermayer @ 2022-03-05 19:16 UTC (permalink / raw)
  To: FFmpeg development discussions and patches


[-- Attachment #1.1: Type: text/plain, Size: 1321 bytes --]

On Fri, Mar 04, 2022 at 04:03:07PM +0100, Niklas Haas wrote:
> From: Niklas Haas <git@haasn.dev>
> 
> Using the venerable HEADER.txt as a small file to load.
> ---
>  libavutil/tests/opt.c    | 38 +++++++++++++++++++++++++++++++++++++-
>  tests/fate/libavutil.mak |  2 +-
>  tests/ref/fate/opt       |  4 ++++
>  3 files changed, 42 insertions(+), 2 deletions(-)

Please add tests which tries to load
id_rsa
~/.ssh/id_rsa
shadow
/etc/shadow
.bash_history
...

The idea here is of course that such attempts fail

Also document the security implications of this feature in 
doc/APIchanges / release notes if there is a security implication

Adjusting the parameters of most components could previously
not read arbitrary files so a application could previously
pass a string from a untrusted user to it.
If this changes it needs to be justfied and documented
If it doesnt change and its still safe that should be documented.
If it depends on whitelists and callbacks that should be actually implemented
in ffmpeg and the relevant examples 

And i do like this feature, if it can be done without security issues

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [FFmpeg-devel] [PATCH 2/2] lavu/tests/opts: add tests for filepath options
  2022-03-05 19:16   ` Michael Niedermayer
@ 2022-03-08  7:47     ` J. Dekker
  2022-03-08 13:36       ` Michael Niedermayer
  0 siblings, 1 reply; 7+ messages in thread
From: J. Dekker @ 2022-03-08  7:47 UTC (permalink / raw)
  To: FFmpeg development discussions and patches



On 5 Mar 2022, at 20:16, Michael Niedermayer wrote:

> On Fri, Mar 04, 2022 at 04:03:07PM +0100, Niklas Haas wrote:
>> From: Niklas Haas <git@haasn.dev>
>>
>> Using the venerable HEADER.txt as a small file to load.
>> ---
>>  libavutil/tests/opt.c    | 38 +++++++++++++++++++++++++++++++++++++-
>>  tests/fate/libavutil.mak |  2 +-
>>  tests/ref/fate/opt       |  4 ++++
>>  3 files changed, 42 insertions(+), 2 deletions(-)
>
> Please add tests which tries to load
> id_rsa
> ~/.ssh/id_rsa
> shadow
> /etc/shadow
> .bash_history
> ...
>
> The idea here is of course that such attempts fail

There is absolutely no way we can or should try to implement a path based blacklist. Untrusted inputs should be sanitised externally by whichever script is being used to call ffmpeg.

> Also document the security implications of this feature in
> doc/APIchanges / release notes if there is a security implication
>
> Adjusting the parameters of most components could previously
> not read arbitrary files so a application could previously
> pass a string from a untrusted user to it.
> If this changes it needs to be justfied and documented
> If it doesnt change and its still safe that should be documented.
> If it depends on whitelists and callbacks that should be actually implemented
> in ffmpeg and the relevant examples
>
> And i do like this feature, if it can be done without security issues

There aren't any extra security implications here, if a user is allowed to specify filter arguments themselves then they can already use the movie/amovie filter etc. This new option is just a way to unify the way in which filters which already (and will) require to load files can do so.

-- 
J. Dekker
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [FFmpeg-devel] [PATCH 1/2] lavu: add syntax for loading AV_OPT_TYPE_BINARY from files
  2022-03-04 15:03 [FFmpeg-devel] [PATCH 1/2] lavu: add syntax for loading AV_OPT_TYPE_BINARY from files Niklas Haas
  2022-03-04 15:03 ` [FFmpeg-devel] [PATCH 2/2] lavu/tests/opts: add tests for filepath options Niklas Haas
@ 2022-03-08 11:48 ` Anton Khirnov
  2022-03-08 12:53   ` Niklas Haas
  1 sibling, 1 reply; 7+ messages in thread
From: Anton Khirnov @ 2022-03-08 11:48 UTC (permalink / raw)
  To: FFmpeg development discussions and patches; +Cc: Niklas Haas

Quoting Niklas Haas (2022-03-04 16:03:06)
> From: Niklas Haas <git@haasn.dev>
> 
> I arbitrarily decided to use the syntax 'opt=@filename' to match e.g.
> `curl -Ffield=@filename`, and also because @ is not a valid hex
> character, nor does it conflict with any other common shell or ffmpeg
> syntax.
> 
> This is arguably somewhat clunky because it does not round-trip with
> av_opt_get - you will get back a hex interpretation of the loaded file,
> rather than the filename it was loaded from. It also implies a (perhaps
> unnecessary) memcpy from mapped file memory into a allocated memory.
> This is unfortunately necessary because there's no way for us to know
> whether av_free or av_file_unmap is needed to clean up previous option
> values.
> 
> The motivating use case was the introduction of several new binary
> options for vf_libplacebo, but other filters that currently rely on
> manual file-path loading could benefit from it as well.

Sorry, I think having an arbitrary file loader in the options parser
will be an endless security nightmare.

The alternative I had in mind was having ffmpeg.c itself do the file
loading. This will be require some modification of the options parsing
code in cmdutils.c and also extending the mechanisms we use to pass
options to filters.

I can try to make a POC in a few days.

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [FFmpeg-devel] [PATCH 1/2] lavu: add syntax for loading AV_OPT_TYPE_BINARY from files
  2022-03-08 11:48 ` [FFmpeg-devel] [PATCH 1/2] lavu: add syntax for loading AV_OPT_TYPE_BINARY from files Anton Khirnov
@ 2022-03-08 12:53   ` Niklas Haas
  0 siblings, 0 replies; 7+ messages in thread
From: Niklas Haas @ 2022-03-08 12:53 UTC (permalink / raw)
  To: FFmpeg development discussions and patches

On Tue, 08 Mar 2022 12:48:35 +0100 Anton Khirnov <anton@khirnov.net> wrote:
> Quoting Niklas Haas (2022-03-04 16:03:06)
> > From: Niklas Haas <git@haasn.dev>
> > 
> > I arbitrarily decided to use the syntax 'opt=@filename' to match e.g.
> > `curl -Ffield=@filename`, and also because @ is not a valid hex
> > character, nor does it conflict with any other common shell or ffmpeg
> > syntax.
> > 
> > This is arguably somewhat clunky because it does not round-trip with
> > av_opt_get - you will get back a hex interpretation of the loaded file,
> > rather than the filename it was loaded from. It also implies a (perhaps
> > unnecessary) memcpy from mapped file memory into a allocated memory.
> > This is unfortunately necessary because there's no way for us to know
> > whether av_free or av_file_unmap is needed to clean up previous option
> > values.
> > 
> > The motivating use case was the introduction of several new binary
> > options for vf_libplacebo, but other filters that currently rely on
> > manual file-path loading could benefit from it as well.
> 
> Sorry, I think having an arbitrary file loader in the options parser
> will be an endless security nightmare.
> 
> The alternative I had in mind was having ffmpeg.c itself do the file
> loading. This will be require some modification of the options parsing
> code in cmdutils.c and also extending the mechanisms we use to pass
> options to filters.
> 
> I can try to make a POC in a few days.

I think that is the better approach, too. I went for this approach
because it was the easiest to implement, not because it makes the most
sense.

I do think that it's fine for ffmpeg.c to do this, but springing it upon
unsuspecting API users *in general* is, well, in retrospect, not
something I want to have my name attached to.

I think that I would drop the second half of this commit (keeping only
the introduction of `av_set_string_from_filepath`), and then make
ffmpeg.c use it for cmdlist arguments starting with '@' as a separate
commit.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [FFmpeg-devel] [PATCH 2/2] lavu/tests/opts: add tests for filepath options
  2022-03-08  7:47     ` J. Dekker
@ 2022-03-08 13:36       ` Michael Niedermayer
  0 siblings, 0 replies; 7+ messages in thread
From: Michael Niedermayer @ 2022-03-08 13:36 UTC (permalink / raw)
  To: FFmpeg development discussions and patches


[-- Attachment #1.1: Type: text/plain, Size: 3063 bytes --]

On Tue, Mar 08, 2022 at 08:47:17AM +0100, J. Dekker wrote:
> 
> 
> On 5 Mar 2022, at 20:16, Michael Niedermayer wrote:
> 
> > On Fri, Mar 04, 2022 at 04:03:07PM +0100, Niklas Haas wrote:
> >> From: Niklas Haas <git@haasn.dev>
> >>
> >> Using the venerable HEADER.txt as a small file to load.
> >> ---
> >>  libavutil/tests/opt.c    | 38 +++++++++++++++++++++++++++++++++++++-
> >>  tests/fate/libavutil.mak |  2 +-
> >>  tests/ref/fate/opt       |  4 ++++
> >>  3 files changed, 42 insertions(+), 2 deletions(-)
> >
> > Please add tests which tries to load
> > id_rsa
> > ~/.ssh/id_rsa
> > shadow
> > /etc/shadow
> > .bash_history
> > ...
> >
> > The idea here is of course that such attempts fail
> 
> There is absolutely no way we can or should try to implement a path based blacklist.

did i ask for one ?
what i asked for is that you write an exploit to show that it fails.


> Untrusted inputs should be sanitised externally by whichever script is being used to call ffmpeg.

my suggestion isnt really affected by this, please implement a test of this
you can put a script around the call to ffmpeg in the fate test but show that
it achieves the security.

If you cannot do this, then please do not suggest that this is the way
to sanitize untrusted data.


> 
> > Also document the security implications of this feature in
> > doc/APIchanges / release notes if there is a security implication
> >
> > Adjusting the parameters of most components could previously
> > not read arbitrary files so a application could previously
> > pass a string from a untrusted user to it.
> > If this changes it needs to be justfied and documented
> > If it doesnt change and its still safe that should be documented.
> > If it depends on whitelists and callbacks that should be actually implemented
> > in ffmpeg and the relevant examples
> >
> > And i do like this feature, if it can be done without security issues
> 
> There aren't any extra security implications here, if a user is allowed to specify filter arguments themselves then they can already use the movie/amovie filter etc. This new option is just a way to unify the way in which filters which already (and will) require to load files can do so.

hmm

So above you say "Untrusted inputs should be sanitised externally by whichever script is being used to call ffmpeg."
and that script now lets say blocks movie and amovie (and others)
before your patch thats safe, afterwards its not
how would the developer know that a git pull --rebase requires him
to rewrite that script? 

Or maybe the script has a list of safe filters and safe arguments, maybe
scale, crop, and a few others with width/height and so on
such script needs an update too if the binary option gains the ability
to read arbitrary files.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-03-08 13:36 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-04 15:03 [FFmpeg-devel] [PATCH 1/2] lavu: add syntax for loading AV_OPT_TYPE_BINARY from files Niklas Haas
2022-03-04 15:03 ` [FFmpeg-devel] [PATCH 2/2] lavu/tests/opts: add tests for filepath options Niklas Haas
2022-03-05 19:16   ` Michael Niedermayer
2022-03-08  7:47     ` J. Dekker
2022-03-08 13:36       ` Michael Niedermayer
2022-03-08 11:48 ` [FFmpeg-devel] [PATCH 1/2] lavu: add syntax for loading AV_OPT_TYPE_BINARY from files Anton Khirnov
2022-03-08 12:53   ` Niklas Haas

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git