|
From: | Ben Woodcroft |
Subject: | Re: ISO image available for testing! |
Date: | Wed, 6 Dec 2017 11:17:30 +1000 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
On 06/12/17 10:52, Mark H Weaver wrote:
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:Hi Ludovic, address@hidden (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.
(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
[Prev in Thread] | Current Thread | [Next in Thread] |