With an individual report of it fixing graphicsmagick build, this is now unmasked into ~arch.
Happy festivities Ühel kenal päeval, R, 30.12.2016 kell 00:22, kirjutas Mart Raudsepp: > 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 >
