Improve GStreamer plugin resolution

[philip-lamb]

Improve GStreamer plugin resolution; 1) prefer module path over exe p…ath (e.g. in case where servo is embedded in a Framework) 2) Support standard GStreamer plugin path environment variable.

---

• ./mach build -d does not report any errors
• ./mach test-tidy does not report any errors

• There are tests for these changes OR

[mrobinson]

Sorry for the delay in reviewing this. I have a few concerns about this and around the GStreamer plugin registry in general. Do we really want Servo to be loading random plugins off of the system? From what I understand our code is written with a particular version of GStreamer in mind so it doesn't make sense to try to load incompatible plugins. Not to mention security issues with loading and executing unknown binary code.

[philip-lamb]

From what I understand our code is written with a particular version of GStreamer in mind so it doesn't make sense to try to load incompatible plugins. Not to mention security issues with loading and executing unknown binary code.

I can't comment on the Windows situation, but on Mac OS Gatekeeper enforces the requirement that by default an app can only load binaries signed with the same certificate as the app. In Servo's case, this includes the GStreamer plugins (anything opened with dlopen). Since the GStreamer binaries are distributed unsigned when we sign them we're taking responsibility for the code they contain. Changing the location of them on the system doesn't change that aspect.

Allowing the configuration of where to look for the plugins (rather than hardcoding a subfolder in the app bundle) allows a bit more flexibility in the packaging. For example, I'm using libservo itself inside a plugin loaded into a third-party app (Unity), and thus looking inside the app bundle for GStreamer plugins always fails (as it is hardcoded to look inside Unity's app bundle).

There is a bigger question I guess around GStreamer itself and how much we trust it in general.