[rb-general] file(1) now with seccomp support enabled
eschwartz at archlinux.org
Mon Jul 22 21:55:43 UTC 2019
On 7/22/19 5:25 PM, Chris Lamb wrote:
> [Adding rb-general at lists.reproducible-builds.org to CC]
> Hi Christoph,
>> Overall, I'm just asking to keep an eye on possible breakage, also
>> check the kernel log.
> I noticed that there were a number of recent regressions in previously
> reproducible Java packages being tested by the Reproducible Builds
> project's CI platform which I could identify as being caused by our
> strip-nondeterminism tool.
> However, as there was a very recent change to some strip-nondeterminism
> code that uses "monkey patching" I was predisposed to believe that was
> the cause, but it eventually turned out to be the call to file(1)
> missing a --no-sandbox parameter (where supported / appropriate).
> It did not even occur to check my kernel log as you suggest — it was
> only when quickly hacking in a:
> strace -eexecve -f dh_strip_nondeterminism
> … to my test package that I figured the file(1) process was being
> killed (without returning any output) with SIGCHLD that things were
> perhaps lower-level in nature. This has been resolved in strip-
> nondeterminism 1.3.0, uploaded this afternoon.
> This mail is not a request for anything, but rather a general heads-up
> for you and a way of "keyword stuffing" various terms the above
> paragraphs into search indexes for the benefit of others looking for
> perhaps-obscure issue like this in the future. It is also an implicit
> thanks for pushing security hardening features. :)
> Best wishes,
I notice this is fixed in
by doing regexes on the output of `file --help`, because the file(1)
program does not support the option as a no-op on non-seccomp-enabled
Over in Arch Linux we have opted instead to disable seccomp in file(1)
entirely -- it completely breaks common workflows that require looking
at files, and there's no way an application can actually know how to
make it work. The solution to the problem is apparently "guess whether
it is enabled, and only if so, disable it again", so much for "security".
In fact, makepkg (dpkg-buildpackage equivalent) relied on it and was
broken for any source files that used compression other than zlib, so it
broke both reproducible and non-reproducible packaging... and surely
there are other programs that care more about compressed file detection
than about sandboxing.
Arch Linux Bug Wrangler and Trusted User
More information about the rb-general