On 06/12/17 10:52, Mark H Weaver wrote:
Hi Ludovic,
l...@gnu.org (Ludovic Courtès) writes:
91c9b5d01 * packages: 'package-grafts' trims native inputs.
[...]
Long story short: we were flagging native inputs as potential sources of
grafts even though, by definition, native inputs are not referred to at
run time.
I agree that this *should* never happen, but I see little reason for
confidence that it never happens in actual fact.
What would happen if a reference to a native-input *was* present in the
build outputs? The reason I ask is that, for security reasons, it's
obviously very important to reliably avoid using ungrafted software at
run time.
I'm concerned that this recent change could cause minor
nearly-undetectable packaging mistakes to become major security holes.
One solution would be to explicitly check build outputs for references
to native-inputs, and to force a build failure in that case.
I believe there are a number of cases of this that happen when binaries
are wrapped with paths derived from getenv, e.g. this phase in bamm:
(add-after 'install 'wrap-executable
(lambda* (#:key outputs #:allow-other-keys)
(let* ((out (assoc-ref outputs "out"))
(path (getenv "PATH")))
(wrap-program (string-append out "/bin/bamm")
`("PATH" ":" prefix (,path))))
#t))
It would be good to stop using getenv for this, for the reasons
described here and others e.g. non-reproducibility, unnecessary
dependencies etc.
Is there some easy way to "getenv" excluding unwanted components of an
environment variable?
Thanks, ben