Mangle hardware library builtin paths, in libs bundled into AppImage builds

[ferdnyc]

This PR adds a script (installer/mangle-hw-libs.sh) which uses sed to modify the contents of libvdpau.so.1 and libva.so.1, replacing the hardcoded driver paths they contain with modified ones that point into the AppImage, instead of at the system drivers.

Since we don't bundle hardware driver libs, this will have the effect of disabling those libraries' access to the hardware drivers, preventing crashes due to mismatched driver versions on many systems.

See the extensive discussion in #3210 for rationale and details.

Fixes #3210, possibly others (though not any Windows crash-on-opening-Preferences issues)

[SuslikV]

Bit-hack is bad decision. No better workarounds?

[ferdnyc]

Bit-hack is bad decision. No better workarounds?

There really aren't. The paths are compiled into the libraries, which we need because they're linked with other libraries in use, but we also need them to not try to access those paths on the host system. Short of a fully-virtualized container that restricts access to the filesystem beyond the sandbox, monkeypatching the hardcoded paths is the best solution anyone's come up with. It's actually a time-honored technique that goes back decades.

Someday it may stop working (like, when library objects are signed and authenticated), but that day isn't anywhere in sight for enduser, non-hardened Linux systems generally.

The only other option would be to build our own custom versions of the libs from patched sources, and there are plenty of downsides to that approach as well.

[ferdnyc]

I wrote the expressions as safely as possible, out of an abundance of caution, and sed will simply do nothing at all if it doesn't find the exact paths it's expecting in the binaries it scans.

Like, for this replacement:

openshot-qt/installer/mangle-hw-libs.sh

Lines 32 to 35 in 7613425

	sed -i \
	-e 's,/usr\(/lib/x86_64-linux-gnu/vdpau\),\./\.\.\1,g' \
	-e 's,/usr\(/lib/vdpau\),\./\.\.\1,g' \
	"${hwlib}"

That could be written as sed -i -e 's,/usr/lib,./../lib,g' ${hwlib}, if you feel like breaking your libraries at some point. (And for sure don't accidentally run it on the WRONG library, or you're screwed.) So, despite the temptation, I decided to do exactly not that.

[ferdnyc]

(Although, come to think of it all that backslash-escaping on the periods in the replacement strings really is totally unnecessary, and sure makes it harder to read.)

[SuslikV]

Madness. I think, that AppImage usage ups hype and decreasing reputation.

[ferdnyc]

Madness. I think, that AppImage usage ups hype and decreasing reputation.

Yeah, I'm not particularly a fan either. My issue is that, no matter how well-designed the AppImage format/tools are, they're based on a faulty premise: That it's possible to create distribution-agnostic Linux binary packages. I think that's been pretty handily disproven.

Their punt has been, "Build them for the oldest system available" on the theory that they should then be forwards-compatible on newer systems. That's fine for simple software applications, but the moment you mix in any sort of hardware drivers or APIs it totally breaks down.

Not to mention, it forces the use of outdated and feature-limited APIs even when they are compatible. I'm constantly feeling held back by the need to ensure that new code we write is still compatible with 3-year-old Ubuntu releases. ...Why? If people insist on running 3-year-old Ubuntu releases, they should stick to running 3-year-old OpenShot releases. Otherwise, keep up!

Aaanyway. Merging this, since disabling hardware acceleration across the board in AppImage-land seems to be the safest course of action.