[Webkit-unassigned] [Bug 220781] New: [Flatpak SDK] Flatpak 1.10 environment variable issues

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=220781

            Bug ID: 220781
           Summary: [Flatpak SDK] Flatpak 1.10 environment variable issues
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: lmoura at igalia.com

Flatpak 1.10 changed how environment variables are passed to bwrap, making our current scripts fail. For example, WEBKIT_BUILD_DIR_BIND_MOUNT and the LC_* variables. These are two cases where webkit-bwrap (our python wrapper around bwrap) does not find them in the os.environ dictionary and fails to process.

In the case of WEBKIT_BUILD_DIR_BIND_MOUNT, this is causing the bind-mount from `WebKitBuild/<PORT>/<CONFIG>` (host) to `/app/webkit/WebKitBuild/<CONFIG>` (sandbox) to not be enabled, leading to always building in the `WebKitBuild/<CONFIG>` dir.

In the case of LC_*, this brought back the locale issue fixed by r263397.

Bisecting flatpak, the commit https://github.com/flatpak/flatpak/commit/6d1773d2a54dde9b099043f07a2094a4f1c2f486 (run: Convert all environment variables into bwrap arguments) is the first failure.

Inspecting webkit-bwrap in a call to bash (Tools/Scripts/webkit-flatpak --verbose -c bash + some print's), webkit-bwrap is inkoved three times:

* ldconfig, with a normal os.environ
* flatpak-dbux-proxy, with the augmented os.environ with the extra info from webkit scripts
* bash (actual command). Here things start to differ.

Before the mentioned commit, the last invocation has the same environment as the second one, with all extra information.
But after the commit, now just LC_CTYPE is forwarded to webkit-bwrap.

Trying to use flatpak's `--env=....` did not expose the variable to bwrap, but only to the sandboxed process itself.

Meanwhile, falling back to 1.6.5 (Focal's) seems to be working fine. But as the change comes from a security advisory, there's a chance the changes will be picked by distros in the LTS packages.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210120/406b0457/attachment-0001.htm>