[gentoo-dev] whitelisting the env ebuilds execute in

[gentoo-dev] whitelisting the env ebuilds execute in

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

Subject pretty much says it all.  Currently *everything* from the users env winds up being available to ebuilds.
This complicates the hell out of my job of maintaining env handling (saving, transfering, reloading) in portage-cvs- 
having literally hundreds of env vars defined prior to even adding in the ebuild/eclass/portage env additions.

So... yeah.  Anyone got a good reason why all vars should be dumped into the ebuild environment?  I don't see the 
point in all of my binpkgs having my ECHANGELOG_USER setting, for example.

Assuming no one can come up with a valid reason why the entire user env must be dumped into the compilation 
environment, whitelisting of vars that are allowed in would be the next step.  LINGUAS, EXTRA_ECONF, etc.

Portage cvs already does it's own filtering of the vars it knows don't belong in the env- portage innard vars for 
example, are explicitly removed from any saved env.  The reason behind this is that portage wants to control those 
vars itself, basically striving for a controlled environment for ebuild execution (whether setup phase or compile).

I don't see why the same control shouldn't be extended to the portions of a users env that get pulled in.  
Ultimately, a user can sidestep it also via profile and portage bashrcs (so it's not a total lockdown on the env).

Thoughts?
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] whitelisting the env ebuilds execute in

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Sun, 13 Mar 2005 09:40:16 -0600 Brian Harring <ferringb@gentoo.org>
wrote:
| Assuming no one can come up with a valid reason why the entire user
| env must be dumped into the compilation  environment, whitelisting of
| vars that are allowed in would be the next step.  LINGUAS,
| EXTRA_ECONF, etc.

Will this whitelist be developer-controllable, or will we have to wait
several years any time we want something added to it? I'm thinking
forward to the next time we do an eclass thing like EBEEP_IGNORE...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] whitelisting the env ebuilds execute in

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Sun, Mar 13, 2005 at 03:48:03PM +0000, Ciaran McCreesh wrote:
> On Sun, 13 Mar 2005 09:40:16 -0600 Brian Harring <ferringb@gentoo.org>
> wrote:
> | Assuming no one can come up with a valid reason why the entire user
> | env must be dumped into the compilation  environment, whitelisting of
> | vars that are allowed in would be the next step.  LINGUAS,
> | EXTRA_ECONF, etc.
> 
> Will this whitelist be developer-controllable, or will we have to wait
> several years any time we want something added to it?
At the moment, was thinking of having it be a stackable list, defaults supplied by portage, *potentially* profiles 
can override/adjust it, and ebuilds themselves can request vars be brought in- note that's only possible *after* 
sourcing the ebuild.  Shouldn't be an issue anyways, cause people don't do evil things like env based 
settings/adjustments in the global scope, right? :)

Re: portage controlling things, not the intention.  Wouldn't be trying to move bin/* code into the tree if it were.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] whitelisting the env ebuilds execute in

[Ned Ludd]

On Sun, 2005-03-13 at 10:04 -0600, Brian Harring wrote:
> On Sun, Mar 13, 2005 at 03:48:03PM +0000, Ciaran McCreesh wrote:
> > On Sun, 13 Mar 2005 09:40:16 -0600 Brian Harring <ferringb@gentoo.org>
> > wrote:
> > | Assuming no one can come up with a valid reason why the entire user
> > | env must be dumped into the compilation  environment, whitelisting of
> > | vars that are allowed in would be the next step.  LINGUAS,
> > | EXTRA_ECONF, etc.
> > 
> > Will this whitelist be developer-controllable, or will we have to wait
> > several years any time we want something added to it?

> At the moment, was thinking of having it be a stackable list, defaults supplied by portage, *potentially* profiles 
> can override/adjust it, and ebuilds themselves can request vars be brought in- note that's only possible *after* 
> sourcing the ebuild.  Shouldn't be an issue anyways, cause people don't do evil things like env based 
> settings/adjustments in the global scope, right? :)

So it will be something like $PORTDIR/profiles/env.accept.list in which 
all devs should be able to add to as needed vs having to file bugs and
wait for long periods of time?

> Re: portage controlling things, not the intention.  Wouldn't be trying to move bin/* code into the tree if it were.
> ~harring
-- 
Ned Ludd <solar@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] whitelisting the env ebuilds execute in

[Brian Harring]

On Sun, Mar 13, 2005 at 05:20:15PM -0500, Ned Ludd wrote:
> So it will be something like $PORTDIR/profiles/env.accept.list in which 
> all devs should be able to add to as needed vs having to file bugs and
> wait for long periods of time?
Yeah, pretty much.

Whatever y'all want it to be, I'm just getting bloody sick of seeing 200+ vars in an ebuild execution env, whenever I 
have to go digging into the guts of it.  Beyond that, it is (afaik) a good source of screwy bugs- random user vars 
screwing with things that aren't expected/accounted for.  A blacklist approach isn't sane there, too many 
possibilities.

Not sure who it was who mentioned it (marienz, was that you?), but a per-ebuild GRAB_USER_VARS would likely be sane 
also- that would be checked by the ebuild_processor, and the env var would be set.  This is post sourcing however- 
before setup phase.
~harring
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] whitelisting the env ebuilds execute in

[Thomas de Grenier de Latour]

On Sun, 13 Mar 2005 17:05:31 -0600
Brian Harring <ferringb@gentoo.org> wrote:

> Not sure who it was who mentioned it (marienz, was that you?),
> but a per-ebuild GRAB_USER_VARS would likely be sane also- that
> would be checked by the ebuild_processor, and the env var would
> be set. 

That would have the major benefit that this vars could easily be
listed at "emerge -pv" time, after USE flags, so that users
finally learn the existence of ALSA_CARDS, LIRC_OPTS and friends.
That was the idea behind bug #23826.

-- 
TGL.
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] whitelisting the env ebuilds execute in

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

Brian Harring wrote:	[Sun Mar 13 2005, 10:40:16AM EST]
> So... yeah.  Anyone got a good reason why all vars should be dumped
> into the ebuild environment?  I don't see the point in all of my
> binpkgs having my ECHANGELOG_USER setting, for example.

Sounds like a great idea to me.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] whitelisting the env ebuilds execute in

[Sven Vermeulen]

Ned Ludd wrote:
> So it will be something like $PORTDIR/profiles/env.accept.list in which 
> all devs should be able to add to as needed vs having to file bugs and
> wait for long periods of time?

With an IREQUEST="ALSA_CARDS" for additional, per-ebuild variables?

-- 
  ^__^   And Larry saw that it was Good.
  (oo)                                      Sven Vermeulen
  (__)   http://www.gentoo.org              Documentation & PR
--
gentoo-dev@gentoo.org mailing list