Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@g.o>
To: gentoo-dev@××××××××××××.org
Subject: [gentoo-dev] whitelisting the env ebuilds execute in
Date: Sun, 13 Mar 2005 15:40:55
1 Subject pretty much says it all. Currently *everything* from the users env winds up being available to ebuilds.
2 This complicates the hell out of my job of maintaining env handling (saving, transfering, reloading) in portage-cvs-
3 having literally hundreds of env vars defined prior to even adding in the ebuild/eclass/portage env additions.
5 So... yeah. Anyone got a good reason why all vars should be dumped into the ebuild environment? I don't see the
6 point in all of my binpkgs having my ECHANGELOG_USER setting, for example.
8 Assuming no one can come up with a valid reason why the entire user env must be dumped into the compilation
9 environment, whitelisting of vars that are allowed in would be the next step. LINGUAS, EXTRA_ECONF, etc.
11 Portage cvs already does it's own filtering of the vars it knows don't belong in the env- portage innard vars for
12 example, are explicitly removed from any saved env. The reason behind this is that portage wants to control those
13 vars itself, basically striving for a controlled environment for ebuild execution (whether setup phase or compile).
15 I don't see why the same control shouldn't be extended to the portions of a users env that get pulled in.
16 Ultimately, a user can sidestep it also via profile and portage bashrcs (so it's not a total lockdown on the env).
18 Thoughts?
19 ~harring


Subject Author
Re: [gentoo-dev] whitelisting the env ebuilds execute in Ciaran McCreesh <ciaranm@g.o>
Re: [gentoo-dev] whitelisting the env ebuilds execute in Aron Griffis <agriffis@g.o>