Not sure why, I don't have this issue with GTK builds... With local deps build of GStreamer, the gst plugin scanner is unable to update the registry, just keeps spewing warnings like this: Could not open log file '/home/phil/tmp/gst.log' for writing: No such file or directory Could not open log file '/home/phil/tmp/gst.log' for writing: No such file or directory 0:00:00.001719713 19 0x242eef0 WARN GST_PLUGIN_LOADING gstplugin.c:491:gst_plugin_register_func: plugin "/var/home/phil/WebKit/WebKitBuild/deps-build/subprojects/gstreamer-full/subprojects/gstreamer/p lugins/elements/libgstcoreelements.so" has incompatible version (plugin: 1.23, gst: 1.22), not loading ... And also where can I write files now? home seems readonly :( Setting WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 works around the bug.
There's no way BubblewrapLauncher could plausibly be expected to know that you've installed GStreamer inside the WebKit build directory and it needs to mount the build directory in the sandbox. I assume this deps-build was never tested with the sandbox enabled until now? You can review bindGStreamerData in BubblewrapLauncher.cpp to see how it decides to mount particular locations. (In reply to Philippe Normand from comment #0) > And also where can I write files now? home seems readonly :( It would not be useful for it to be writable, because it's not the same home as on your host system and you'd be writing to the abyss. Many directories *within* home are mounted from the host, though, e.g., ~/.local/share/gstreamer-1.0. So if you're just debugging, you this is one of various places you can write stuff to. (Corollary: the data in these directories is expected to be malicious, because the compromised web process can write to them.)
This local deps build of GStreamer, is it specific to GStreamer? Not something we do with other dependencies? I think it's OK to go a little crazy with mounting build directory locations, but we'd need to pass that along via some preprocessor define, and restrict it to ENABLE(DEVELOPER_MODE).
(In reply to Michael Catanzaro from comment #1) > There's no way BubblewrapLauncher could plausibly be expected to know that > you've installed GStreamer inside the WebKit build directory and it needs to > mount the build directory in the sandbox. I assume this deps-build was never > tested with the sandbox enabled until now? > It was, but on a different setup (flatpak SDK). I forgot to mention I'm trying this now from a Toolbx running a F38 container...
(In reply to Michael Catanzaro from comment #2) > This local deps build of GStreamer, is it specific to GStreamer? Not > something we do with other dependencies? > I'm using it for GStreamer, but in the end it's just a meson project aggregating whatever other meson projects you want. See Tools/flatpak/local-projects/meson.build > I think it's OK to go a little crazy with mounting build directory > locations, but we'd need to pass that along via some preprocessor define, > and restrict it to ENABLE(DEVELOPER_MODE). OK, I can try something in that direction.
Pull request: https://github.com/WebKit/WebKit/pull/15444
Committed 265773@main (47a42208eb06): <https://commits.webkit.org/265773@main> Reviewed commits have been landed. Closing PR #15444 and removing active labels.