Marton Balint (2018-02-23):
> The environment variable contains the directory to the library, not the
> library name itself.

So it reinvents LD_LIBRARY_PATH. Probably badly.

> LD_LIBRARY_PATH, LD_PRELOAD is an environment variable as well, so I don't
> see why it is different from security standpoint.

It is not different in concept, but the details were designed by very
competent hackers. Yet, over the years, numerous security issues related
to these features have been found and fixed.

> And it's not unprecedented, there is FREI0R_PATH, or LADSPA_PATH for
> example. Okay, these are plugins, so not entirely the same thing, yet the
> approach is similar.

I had not yet thought of it. This is worrisome.

> I'd rather say that we should add 100+ lines of code because:
>  - it fixes some portability issues with the library names

So, in order to fix the portability issues of this library, any
application that uses it is supposed to implement these 100+ lines of

I say: let them fix their crap.

>  - dynamic loading alone has some pros (e.g. not needing the SDK
>    on every machine where you use your built ffmpeg)

Sorry, you are wrong, this is not how dynamic loading works. You need
the shared library (and possibly supporting data files), whether you
load it through dlopen() or through NEEDED.

>  - we can use the SDK suggested way to find the library using an
>    environment variable

Let them fix their crap.

>  - the author who is the de facto maintainer prefers it this way

Let them fix their tastes.

> I also tried to help making the code "less ugly" in my review.

Les ugly is still ugly.


  Nicolas George

Attachment: signature.asc
Description: Digital signature

ffmpeg-devel mailing list

Reply via email to