OpenSSL's module builds with --openssldir=/app/ssl, but nothing populates
/app/ssl/certs, so SSL_CTX_set_default_verify_paths() always fails to find
any CA. Point SSL_CERT_FILE at the runtime's real bundle (/etc/ssl/cert.pem)
via finish-args instead. Verified with --headless=text against example.com,
news.ycombinator.com, and google.com.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Found and fixed, in order, while actually trying to run the built
app (not just build it):
1. Fontconfig loads its config after the sandbox restricts filesystem
access, so it fails (upstream #11775, open, filed against NixOS
but general to any Linux sandbox). Adapted the issue's own
suggested fix to this checkout's current GlobalFontConfig::get().
2. WebContent crash-loops with "Landlock must be applied before the
process starts a second thread" -- a check that, per git log,
didn't exist before commit 3fea952607 (11 days before our pin),
added while fixing an analogous bug in Compositor (GPU driver
threads starting before Landlock). That fix reordered Compositor's
startup; WebContent has the same problem and was never updated to
match. Root-caused via temporary /proc/self/task diagnostics: the
second thread is OpenSSL's thread pool and SDL's gamepad hotplug
thread, both started before the sandbox. Fixed by moving both
after RendererSandbox::apply_sandbox(), mirroring the precedent.
3. Moving SDL's init that late surfaced a third issue: its libusb
backend's event thread hits a seccomp violation (sendmmsg on a
netlink socket) the policy doesn't grant. SDL_HINT_HIDAPI_LIBUSB=0
didn't avoid it in testing. Rather than widen the seccomp policy
for a feature most pages never use, skip gamepad init entirely
while sandboxed (--disable-sandbox still gets it) -- a real,
documented tradeoff, not a hidden one.
All three are packaged as patches/sandbox-fixes.patch, applied
automatically by task clone/update/apply-patches (none of this is
upstreamed yet, and git reset/clone would otherwise silently wipe
working-tree-only edits). Confirmed working end to end: a real
`flatpak run org.ladybird.Ladybird`, no flags, starts RequestServer,
Compositor, and two WebContent processes, all stay up, pages load,
no crash loop.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
