On Mon, Aug 22, 2005 at 12:24:13PM -0700, Zac Medico wrote:
> warnera6 wrote:
> >>>My preference would go 4, 3, 2 then 1. While Makefiles and configure 
> >>>scripts may be "broken" upstream, how long is it before the breakage 
> >>>goes unnoticed? More importantly, what's the chances of a dev finding 
> >>>the breakage before users? Cleansing the environment to me is akin to 
> >>>using sandbox. It offers protection against misbehaving packages...
> >>>
> >>
> >>Good point. How about if we add environment sandboxing support (in 
> >>addition to filesystem sandboxing) to sandbox.  With an environment 
> >>sandbox, we could detect specifically which variables a build is 
> >>fragile with regard to.  The sandbox would have both filesystem access 
> >>and environment access violation summaries.
> >
> >"environmental sandbox" being similar to sandbox, or the cleansing of 
> >the environment?  The latter is easy, the former...I am not sure how you 
> > begin to detect variable use in bash :/
> >
> 
> AFAIK we can intercept getenv() calls the same way that we intercept 
> filesystem calls.  IMO the white/black/override lists would best be 
> implemented at this level.
Don't think this is the appropriate method, imo- remember sandbox 
doesn't exist on bsd, so the solution wouldn't be across the board 
(resulting in ebuild devs inventing their own that is when required).

Better approach is abusing the env-filtering capabilities written into 
2.1 already- it wouldn't require much to slip it into 
ebuild_processor.
~harring