Hello, So I provided a patch for a sandbox bug hitting bigger projects using -export-symbols-regex with a long list of object files. 3 months ago. Bug has been there since forever, reported 15 months ago, with some good clues to what's up since 9 months. It has been sitting there, collecting dust, with no action from sandbox@ whatsoever. As such, I plan to finally non-maintainer push this fix straight to ~arch as a sandbox-2.10 revision bump once I have my months old GPG machine tree and system updated (this week or early next week). And 2.11, but because that is still p.masked due to it causing issues for XUL stuff (with analysis of what's going on also available since a while now), that's going to be a p.masked revbump alongside the 2.11 masks. If I can't do my gnome-builder bumps that depends on this right away, I might let it simmer in p.mask for some hours or days too, especially if I see some sort of sandbox@ action appearing or some valid objections by the time I get to it.
This is the bug I have fix for: https://bugs.gentoo.org/show_bug.cgi?id=553092 libtool ends up running "nm -B" with the long list of object files as arguments and saves the result in a temporary file (which it'll apply the regex to then), but various shells in some environments (including bash-4.3 and dash) end up trying to glob it and check if it's a dir, calling opendir with the whole commandline as argument. If that is longer than 8196 characters, sandbox gets confused because it internally uses PATH_MAX*2 buffers, it gets cut and things fall over in ways I'm not interested in finding out deeper. At least gnome-builder-3.20+ and graphicsmagick are affected for some (might depend on what their shell is doing). Because of this, gnome-builder hasn't seen version bumps, while the existing version in tree (3.18, it didn't use so many object files in the linker line quite yet back then to trigger the bug) are completely unusable with current stable gtksourceview and co. So, any objections with me pushing in the sandbox revbumps? PS: I'm sure our mozilla team would appreciate also help with sandbox bug 580726, which is a bug in the ptrace fallback, which now gets triggered with the p.masked sandbox 2.11 due to some inherent issues with the default non-ptrace code that were hit in Chrome OS project thing doing some own memory management (and so it fallbacks more often, when it finds custom memory allocation stuff based on some heuristics). The ptrace fallback gets now used with 2.11 for firefox and co as well (probably due to jemalloc usage), and that fallback sandbox codepath is apparently buggy for its more complex case. Alternatively maybe these heuristics could be less triggerhappy to fallback to ptrace. Mart