On 7/22/19 5:25 PM, Chris Lamb wrote:
[Adding [email protected] 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
_______________________________________________
[email protected] mailing list
To change your subscription options, visit
https://lists.reproducible-builds.org/listinfo/rb-general.
To unsubscribe, send an email to
[email protected].
