| 1 |
On Mon, Aug 22, 2005 at 12:24:13PM -0700, Zac Medico wrote: |
| 2 |
> warnera6 wrote: |
| 3 |
> >>>My preference would go 4, 3, 2 then 1. While Makefiles and configure |
| 4 |
> >>>scripts may be "broken" upstream, how long is it before the breakage |
| 5 |
> >>>goes unnoticed? More importantly, what's the chances of a dev finding |
| 6 |
> >>>the breakage before users? Cleansing the environment to me is akin to |
| 7 |
> >>>using sandbox. It offers protection against misbehaving packages... |
| 8 |
> >>> |
| 9 |
> >> |
| 10 |
> >>Good point. How about if we add environment sandboxing support (in |
| 11 |
> >>addition to filesystem sandboxing) to sandbox. With an environment |
| 12 |
> >>sandbox, we could detect specifically which variables a build is |
| 13 |
> >>fragile with regard to. The sandbox would have both filesystem access |
| 14 |
> >>and environment access violation summaries. |
| 15 |
> > |
| 16 |
> >"environmental sandbox" being similar to sandbox, or the cleansing of |
| 17 |
> >the environment? The latter is easy, the former...I am not sure how you |
| 18 |
> > begin to detect variable use in bash :/ |
| 19 |
> > |
| 20 |
> |
| 21 |
> AFAIK we can intercept getenv() calls the same way that we intercept |
| 22 |
> filesystem calls. IMO the white/black/override lists would best be |
| 23 |
> implemented at this level. |
| 24 |
Don't think this is the appropriate method, imo- remember sandbox |
| 25 |
doesn't exist on bsd, so the solution wouldn't be across the board |
| 26 |
(resulting in ebuild devs inventing their own that is when required). |
| 27 |
|
| 28 |
Better approach is abusing the env-filtering capabilities written into |
| 29 |
2.1 already- it wouldn't require much to slip it into |
| 30 |
ebuild_processor. |
| 31 |
~harring |
Archives