[rb-general] file(1) now with seccomp support enabled

[Eli Schwartz]

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:
> 
>      override_dh_strip_non_determinism:
>              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 
https://salsa.debian.org/reproducible-builds/strip-nondeterminism/commit/20b287d8eb20280057dae869f0a06a7c6b7c7107 
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 
file(1) builds.

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.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User