Add Actions on GitHub to build library for platform

[testingbetaversion]

wouldn't it be better to make a build action from GitHub so everyone can create .dll / .dylibs / .so by forking the project and adding l3.wvd file?

[tchebb]

I'd prefer not to encourage people to push .wvd files to GitHub or have them processed by GitHub Actions runners. Projects that commit device private keys have had DMCA takedowns before, so I want to be extra careful to avoid that, even in forks.

However, I do agree that people shouldn't have to build all the Rust code themselves just to use OpenWV. I've been thinking about ways to avoid that, and I'll keep this issue open to track that work. My current plan is to make it possible to build the OpenWV library with no device identity and then embed the identity later via a lightweight script that won't require the Rust toolchain or a C++ compiler. Potentially, that script could even run in the browser.

If I get that working, then I'll turn on GitHub Actions to build official releases of the identity-free library across all supported platforms.

[Uukrull]

Any news about this?

The shipped libwidevinecdm.so for webOS isn't compatible with Kodi inputstream.adaptive and the available libs from ChromeOS can't be used because they are compiled with hard-float and webOS needs soft-float.

I managed to compile OpenWV (many thanks!) for webOS and it seems to work without problems but it can't be bundled with Kodi because of the embedded .wvd

[cscd98]

@tchebb Was about to say the same thing. Any progress on building the library without device identity which could be added at runtime?

[tchebb]

I haven't made much headway. I tried a few approaches last month, but none of them worked. I want a solution that does all of these:

1. Retains support for all browser sandboxes (in practice, Firefox's and Chromium's) on all platforms. You shouldn't need to patch your browser or disable sandboxing to use OpenWV.
2. Lets users attach their .wvd file with little to no additional tooling. Any tooling should be lightweight and easy to run on all platforms. Ideally, that means it can run in a browser, although that shouldn't be the only option.
3. Doesn't require me to develop and maintain lots of platform-specific code unrelated to OpenWV's core functionality (e.g. custom tooling to patch PE, ELF, and Mach-O object files).

Nothing I've tried yet fits the bill. Here are some of the options I've considered:

1. Build the library with an unresolved symbol reference to user configuration (just a .wvd file if I'm lazy, or a serialized struct containing all the fields from config.rs if I'm not) and then insert that symbol post-build so the dynamic loader sees it at load-time. Technically this ought to work decently, but the tooling to patch the object file is hard to build in Rust. The object crate seems like the closest thing, but it doesn't support inserting symbols on all platforms. I could write scripts that shell out to the appropriate OS tools (like objcopy on Linux), but those wouldn't run in the browser and would be fiddly to test.
2. Read configuration from an unresolved symbol, like above, but define that symbol in a separate .so file that users can build and place adjacent to OpenWV. I was excited about this option a couple weeks ago, since the tooling to create an object file from scratch is much better than the tooling to patch an existing one, but unfortunately Firefox's sandbox whitelists the libraries a CDM is allowed to depend on, so it won't work technically—at least not on all browsers.
3. Add a mode where configuration is read from disk or passed in via a custom function that's not part of Google's API. This wouldn't help with sandboxed environments, but it would give people who use Kodi or are willing to disable their browser sandbox an easier solution. I'm hesitant to do this because I think it would encourage people to disable sandboxing, which affects more than just OpenWV.
4. Build OpenWV with a fixed amount of space reserved for a configuration blob, pre-filled with some magic byte sequence, and patch in the configuration by searching for and replacing that byte string. This is very simple and OS-agnostic, but it's pretty hacky since we're just changing bytes in a file without knowing anything about the file's format. In practice, this should work fine for ELF files and I think also unsigned Mach-O files. But I think PE files have checksums of the sections, so I'd probably need some format awareness in order to deal with that.

I'm currently most interested in option 4, but even if it works exactly how I expect it's a decent chunk of work, and I'm not sure when I'll get to it. If any of you have suggestions, I'd love to hear them!