[gentoo-portage-dev] Environment Whitelisting

[gentoo-portage-dev] Environment Whitelisting

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Was talking with Brian about the build environment and how settings were
to be passed into the build environment.

Essentially three scenarios were presented.

1)  The full environment is passed to the build environment.  This was
generally agreed upon to be bad since there are environmental things
that can cause build problems.

2)  The full environment is parsed via a blacklist to strip out
environment settings that are known to be bad for building packages.
This leads to a clean* build environment.  However, maintaining the
blacklist can be a challenge if it grows in size.

(*) clean, meaining all the bad things we know about are not in the
build environment.  This does not account for the bad things we do NOT
know about.

3)  The full environment is parsed via a whitelist to get a list of
environment settings that are known to be good for building packages.
This leads to a clean build environment, as only whitelisted environment
settings are passed in.  However, the whitelist will probably be worse
to maintain than a blacklist.

Both 2) and 3) above have issues where some build variables are bad for
ebuild X but not ebuild Y.  I am unsure how exactly to cover any kind of
situation like that ( and I don't have an example from the tree, save
perhaps LANG=weird-language ).

To me 1) is unacceptable and 3) is the best option.  Feel free to shoot
these down as you see fit ;)

- -Alec Warner (antarus)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQwjjSGzglR5RwbyYAQIAeQ//cGJLLF0BKATfaUjAikiKgJ8miHeMBw9p
UMN+xmB3N48Qj8bEC9qhhisSVZGFUVBuucWX5ObKGOG9vQx2Ry/i3NJG0W124s77
f9lLYOcPBOXV6Wo9F4WQ20SZt+0ktoCe2aphC/aVVyiyQhagtqjud50caBcUVfGq
OlpZLLze9LW5SeqRC5N826kZJh63wP/4YOqqRo5DKjIJb/ahFUT0IZqBVWs2OADD
548yRsBsW4G3n8+JxANbGVeFwPACiWc+DFUBU651X36D01+D/M/a5Cp1f+J+Y2IW
AouTkuzxmu8FgiK1+xNN3hOPM+PiqHfcWT7gBa+5Xb+h19mwgJuQAAD7stQNKxZk
GorIA6GubOx+6qQd4nbzdR7bm2/LUhpC2IOQlIwmMwh2RPYnVp7QRILvsFRGPELV
Fb0/enfwD2EzhwJJKkx5LFOdTFA71RP7WICNUJTbntRWp89aspgPg+gB/6gq9s0t
Hf8oRsHR1Xox0NH09oJTTToxakgjdnSrjUAG42ZqDLRvP1x8FmL6BWbYZ9CIXBaJ
r7wxYCwW6pQGcuCAtZCnc9UEIHXTZuy4btxnrfxAwtT10dJub2BrBo4TSZgRQyKu
++N3nxVb0m8qOgRJYsv4hBb0ybJgrDiqCmvfSgSEJAO1+wKPnR8YhEqsOkNBul4Y
sLBvLF9lJl8=
=AXLx
-----END PGP SIGNATURE-----
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Environment Whitelisting

[Zac Medico]

Alec Warner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Was talking with Brian about the build environment and how settings were
> to be passed into the build environment.
> 
> Essentially three scenarios were presented.
> 
> 1)  The full environment is passed to the build environment.  This was
> generally agreed upon to be bad since there are environmental things
> that can cause build problems.
> 
> 2)  The full environment is parsed via a blacklist to strip out
> environment settings that are known to be bad for building packages.
> This leads to a clean* build environment.  However, maintaining the
> blacklist can be a challenge if it grows in size.
> 
> (*) clean, meaining all the bad things we know about are not in the
> build environment.  This does not account for the bad things we do NOT
> know about.
> 
> 3)  The full environment is parsed via a whitelist to get a list of
> environment settings that are known to be good for building packages.
> This leads to a clean build environment, as only whitelisted environment
> settings are passed in.  However, the whitelist will probably be worse
> to maintain than a blacklist.
> 
> Both 2) and 3) above have issues where some build variables are bad for
> ebuild X but not ebuild Y.  I am unsure how exactly to cover any kind of
> situation like that ( and I don't have an example from the tree, save
> perhaps LANG=weird-language ).
> 
> To me 1) is unacceptable and 3) is the best option.  Feel free to shoot
> these down as you see fit ;)
> 

IMO the whitelist is a bad thing.  I would suggest a blacklist and an override list.  The blacklist simply removes known "problem causing" variables.  The override list allows known "problem causing" variables to be overridden.

Zac
-- 
gentoo-portage-dev@gentoo.org mailing list

[gentoo-portage-dev] Re: Environment Whitelisting

[Drake Wyrm]

Alec Warner <warnera6@egr.msu.edu> wrote:
> Was talking with Brian about the build environment and how settings
> were to be passed into the build environment.
> 
> Essentially three scenarios were presented.
> 
Snip and summary:

1) Pass everything

2) Blacklist and strip bad stuff

3) Whitelist good stuff; strip everything else
> 
> To me 1) is unacceptable and 3) is the best option.  Feel free to
> shoot these down as you see fit ;)

Option 4: Strip everything.

Have portage take a snapshot of the environment and keep it in a hash
(or whatever Python call associative arrays) when it starts. Nothing in
the environment is to be trusted, so flush it. Portage already parses
certain environment variables to establish the build environment; have
portage parse its snapshot to establish the build environment. Nothing
is passed from the original environment; everything passed in the
environment is considered to be a "portage variable". This, I suppose,
is an extreme case of the whitelist.

I don't particularly like option 4, but it is an option.

I much prefer option 1. It's more work for the maintainers, but breakage
from the environment should be fixed in the Makefile and pushed
upstream.

-- 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^ A unix signature isn't a return address, it's the ASCII equivalent of ^
^ a black velvet clown painting. It's a rectangle of carets surrounding ^
^ a quote from a literary giant of weeniedom like Heinlein or Dr. Who.  ^
^   -- Chris Maeda                                                      ^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: Environment Whitelisting

[Zac Medico]

Drake Wyrm wrote:
> 
> I much prefer option 1. It's more work for the maintainers, but breakage
> from the environment should be fixed in the Makefile and pushed
> upstream.
> 

Yeah, I agree that a build that is fragile with regard to environment variables could be an upstream issue.  The advantage of white/black/override list portage feature is that it would provide a way to work around these kinds of problems (until they are fixed upstream).

In #gentoo-portage Alec pointed out that a blacklist would not guarantee a clean build environment to the extent that a whitelist would.  Despite this, I was not convinced that a whitelist is necessary and worth the implementation/maintenance costs.  To support this, I pointed out that portage seems to work well currently, without a whitelist.

Based on this information, I would suggest that the lists, if they get implemented, should exist at both global and per-ebuild levels, and should be optional (not necessarily required).  One thing I like about black/override lists (as opposed to whitelists) is that they would serve to document specifically which environment variable(s) a specific build is fragile with regard to.

Zac
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: Environment Whitelisting

[Kristian Benoit]

On Sun, 2005-08-21 at 21:41 -0700, Zac Medico wrote:
> Yeah, I agree that a build that is fragile with regard to environment
> variables could be an upstream issue.  The advantage of
> white/black/override list portage feature is that it would provide a
> way to work around these kinds of problems (until they are fixed
> upstream).

Another point of view could be that leaving the environment as is would
help providing bugs to the upstream. But I must agree with you that
having it optional would probably be the best thing.

I think the fourth solution would be nice if we have
a /etc/portage/package.env so that if one need to specify an non portage
environment variable, it could be specified on a per packge basis. It
could also be a /etc/portage/package.env.d that contain a per-package
script that set-up the environment for that package.

The script coud be called with the calling environment set a variable
name "keep_variables" to a list of the variables that should be kept for
that particuliar package.

The calling environment could also specify a keep_variables varible so
that we keep those variable in build environment.

Kristian

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

Re: [gentoo-portage-dev] Re: Environment Whitelisting

[Jason Stubbs]

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

On Monday 22 August 2005 12:52, Drake Wyrm wrote:
> Alec Warner <warnera6@egr.msu.edu> wrote:
> > Was talking with Brian about the build environment and how settings
> > were to be passed into the build environment.
> >
> > Essentially three scenarios were presented.
>
> Snip and summary:
>
> 1) Pass everything
>
> 2) Blacklist and strip bad stuff
>
> 3) Whitelist good stuff; strip everything else
>
> > To me 1) is unacceptable and 3) is the best option.  Feel free to
> > shoot these down as you see fit ;)
>
> Option 4: Strip everything.
>
> Nothing is passed from the original environment; everything passed in the
> environment is considered to be a "portage variable". This, I suppose,
> is an extreme case of the whitelist.

Well, I'll go against the flow. ;)

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...

-- 
Jason Stubbs

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

Re: [gentoo-portage-dev] Re: Environment Whitelisting

[Zac Medico]

Jason Stubbs wrote:
> On Monday 22 August 2005 12:52, Drake Wyrm wrote:
> 
>>Alec Warner <warnera6@egr.msu.edu> wrote:
>>
>>>Was talking with Brian about the build environment and how settings
>>>were to be passed into the build environment.
>>>
>>>Essentially three scenarios were presented.
>>
>>Snip and summary:
>>
>>1) Pass everything
>>
>>2) Blacklist and strip bad stuff
>>
>>3) Whitelist good stuff; strip everything else
>>
>>
>>>To me 1) is unacceptable and 3) is the best option.  Feel free to
>>>shoot these down as you see fit ;)
>>
>>Option 4: Strip everything.
>>
>>Nothing is passed from the original environment; everything passed in the
>>environment is considered to be a "portage variable". This, I suppose,
>>is an extreme case of the whitelist.
> 
> 
> Well, I'll go against the flow. ;)
> 
> 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.

Zac
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: Environment Whitelisting

[warnera6]

Zac Medico wrote:
> Jason Stubbs wrote:
> 
>> On Monday 22 August 2005 12:52, Drake Wyrm wrote:
>>
>>> Alec Warner <warnera6@egr.msu.edu> wrote:
>>>
>>>> Was talking with Brian about the build environment and how settings
>>>> were to be passed into the build environment.
>>>>
>>>> Essentially three scenarios were presented.
>>>
>>>
>>> Snip and summary:
>>>
>>> 1) Pass everything
>>>
>>> 2) Blacklist and strip bad stuff
>>>
>>> 3) Whitelist good stuff; strip everything else
>>>
>>>
>>>> To me 1) is unacceptable and 3) is the best option.  Feel free to
>>>> shoot these down as you see fit ;)
>>>
>>>
>>> Option 4: Strip everything.
>>>
>>> Nothing is passed from the original environment; everything passed in 
>>> the
>>> environment is considered to be a "portage variable". This, I suppose,
>>> is an extreme case of the whitelist.
>>
>>
>>
>> Well, I'll go against the flow. ;)
>>
>> 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 :/

I am leaning more toward the 2,4,3,1 angle.  I find the information that 
variable X breaks builds more useful than having a clean environment ALL 
the time.  I am satisfied as long as a clean environment is an option 
for those who wish their environment to be all nice and pretty ;)

I don't see exactly the difference between 4) and 3) however...4 seems 
to be just a python enforced version of 3).

-Alec Warner (antarus)
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: Environment Whitelisting

[Zac Medico]

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.

Zac
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: Environment Whitelisting

[Brian Harring]

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

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

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

Re: [gentoo-portage-dev] Re: Environment Whitelisting

[Kristian Benoit]

On Mon, 2005-08-22 at 12:24 -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.

getenv is'nt a system call. It is in the section 3 of the manual and I
tried this:

#include <unistd.h>

int main ()
{
    getenv("USER");
    return 0;
}

// $ strace ./test 2>&1 | grep USER
// $ strace ./test 2>&1 | grep foo # where $USER=foo

and both output is empty. I have'nt checked how sandbox is working for
filesystem, but filesystem related calls are at somepoint forwarded to
the kernel and that is probably where sandbox is hooking. But as getenv
is'nt a syscall, you could probably could probably find a way to get it
to working by not linking on libc, define getenv and load libc with
dlopen, but that will be a pain. As you need to libc to get your main
called.

Kristian

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

Re: [gentoo-portage-dev] Re: Environment Whitelisting

[Brian Harring]

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

On Mon, Aug 22, 2005 at 09:57:46PM -0400, Kristian Benoit wrote:
> On Mon, 2005-08-22 at 12:24 -0700, Zac Medico wrote:
> > 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.
>
> getenv is'nt a system call.

Nor is glibc's open call, although it hands off to a syscall .
LD_PRELOAD just inserts (essentially) it's functions into the symbol 
resolution order; your symbols get used rather then those from the 
lib.

It's possible, I just don't like it. :)
~harring

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

Re: [gentoo-portage-dev] Environment Whitelisting

[Marius Mauch]

On 08/21/05  Alec Warner wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Was talking with Brian about the build environment and how settings
> were to be passed into the build environment.
> 
> Essentially three scenarios were presented.
> 
> 1)  The full environment is passed to the build environment.  This was
> generally agreed upon to be bad since there are environmental things
> that can cause build problems.
> 
> 2)  The full environment is parsed via a blacklist to strip out
> environment settings that are known to be bad for building packages.
> This leads to a clean* build environment.  However, maintaining the
> blacklist can be a challenge if it grows in size.
> 
> (*) clean, meaining all the bad things we know about are not in the
> build environment.  This does not account for the bad things we do NOT
> know about.
> 
> 3)  The full environment is parsed via a whitelist to get a list of
> environment settings that are known to be good for building packages.
> This leads to a clean build environment, as only whitelisted
> environment settings are passed in.  However, the whitelist will
> probably be worse to maintain than a blacklist.
> 
> Both 2) and 3) above have issues where some build variables are bad
> for ebuild X but not ebuild Y.  I am unsure how exactly to cover any
> kind of situation like that ( and I don't have an example from the
> tree, save perhaps LANG=weird-language ).
> 
> To me 1) is unacceptable and 3) is the best option.  Feel free to
> shoot these down as you see fit ;)

Well, codewise 2) and 3) aren't that different (one is just the
inversion of the other), so why not implement both, make a config
setting for it and get empirical data to find the "best" solution?
Actually don't even need a config switch, just detect if a blacklist or
a whitelist is present and use them then.

Theoretical discussions about this are pointless IMO without
numbers/facts to back things up.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Environment Whitelisting

[Brian Harring]

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

On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote:
> Theoretical discussions about this are pointless IMO without
> numbers/facts to back things up.
I'd posit theroetical discussions about this are pointless without 
getting ebuild dev's to give a yay/nay on whether they want it or not; 
not much for trying to force it down their throats if they don't want 
it (more work, essentially).
~harring

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

Re: [gentoo-portage-dev] Environment Whitelisting

[warnera6]

Brian Harring wrote:
> On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote:
> 
>>Theoretical discussions about this are pointless IMO without
>>numbers/facts to back things up.
> 
> I'd posit theroetical discussions about this are pointless without 
> getting ebuild dev's to give a yay/nay on whether they want it or not; 
> not much for trying to force it down their throats if they don't want 
> it (more work, essentially).
> ~harring

is this a call to move the discussion to -dev? :)
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Environment Whitelisting

[Marius Mauch]

On 08/22/05  Brian Harring wrote:

> On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote:
> > Theoretical discussions about this are pointless IMO without
> > numbers/facts to back things up.
> I'd posit theroetical discussions about this are pointless without 
> getting ebuild dev's to give a yay/nay on whether they want it or not;
> 
> not much for trying to force it down their throats if they don't want 
> it (more work, essentially).

That too. But providing them with some numbers will certainly have an
effect on their decision (especially if it shows that it doesn't really
affect them ;)

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Environment Whitelisting

[Brian Harring]

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

On Mon, Aug 22, 2005 at 11:59:54PM +0200, Marius Mauch wrote:
> On 08/22/05  Brian Harring wrote:
> 
> > On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote:
> > > Theoretical discussions about this are pointless IMO without
> > > numbers/facts to back things up.
> > I'd posit theroetical discussions about this are pointless without 
> > getting ebuild dev's to give a yay/nay on whether they want it or not;
> > 
> > not much for trying to force it down their throats if they don't want 
> > it (more work, essentially).
> 
> That too. But providing them with some numbers will certainly have an
> effect on their decision (especially if it shows that it doesn't really
> affect them ;)
Rather hard to back it up though, without specialized knowledge in 
(effectively) the whole tree- either we do it, or we ask nicely those 
who are supposed to have such knowledge :)

I can rattle off a couple of env vars that screw things up, but how 
many of us are aware that an exported ARCH screws with kernel builds 
fex?

I'd punt it to them, and find out what they think (tiz the route I 
took when I brought this up last).

Explicit whitelisting is great for getting closer to deterministic 
builds, but it's a helluva overhead on a side note.
~harring

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

Re: [gentoo-portage-dev] Environment Whitelisting

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Harring wrote:
> On Mon, Aug 22, 2005 at 11:59:54PM +0200, Marius Mauch wrote:
> 
>>On 08/22/05  Brian Harring wrote:
>>
>>
>>>On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote:
>>>
>>>>Theoretical discussions about this are pointless IMO without
>>>>numbers/facts to back things up.
>>>
>>>I'd posit theroetical discussions about this are pointless without 
>>>getting ebuild dev's to give a yay/nay on whether they want it or not;
>>>
>>>not much for trying to force it down their throats if they don't want 
>>>it (more work, essentially).
>>
>>That too. But providing them with some numbers will certainly have an
>>effect on their decision (especially if it shows that it doesn't really
>>affect them ;)
> 
> Rather hard to back it up though, without specialized knowledge in 
> (effectively) the whole tree- either we do it, or we ask nicely those 
> who are supposed to have such knowledge :)
> 
> I can rattle off a couple of env vars that screw things up, but how 
> many of us are aware that an exported ARCH screws with kernel builds 
> fex?
> 
> I'd punt it to them, and find out what they think (tiz the route I 
> took when I brought this up last).
> 
> Explicit whitelisting is great for getting closer to deterministic 
> builds, but it's a helluva overhead on a side note.
> ~harring

I'm kinda with genone on implementing both ( since they are similar ).
If it's decided that blacklisting is easier to maintain, I can always
make up my own whitelist for pkg-foo and apply it and if it works submit
it as a bug ( or even some other whitelist database? ) and thus can
gaurentee that my package was built 'correctly'(TM).  I think this would
be important in fex, an enterprise distribution type deal where the
build env is important to some.  Put the whitelists in the tree and have
them --excluded by default, so only the users that use them have to
downlaod them.

Regardless I'd like to see what actual people who write and manage
ebuilds think, I've only written a few and I don't have much experience
in that area.  ( Spanky, solar, etc... the crazy ones ) :)

- -Alec Warner (antarus)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQwpTUmzglR5RwbyYAQKPOA/+PbhtDYbbasHP9ZDa2SwTN+YVQRfXEfBt
QwqjmtmdSyGSsLJL7C5PtASL/lLUK0z6uI2LmCniHctvIzvHd7/dAZO8deq4Hqcb
18CgXZucwqvGnLhPIC23Z7CTXb3dUf60WTbwjkP4vTmywRtWr3eOqGIZ03pgjrBr
GDtb+onEGn8lSMxdqRuUxCvFnyz+QIaX2ysOahH/qKRIcJXh4w/zFQrDy+9olSpy
CAkaZLrOplRKZSSkz5i/W1dpKioa7fa3FXD43a7uWXzoRsLNxivyhNqtJJ34rnPI
UexjElpelGlnw4zdDGzq5waYDpwUPfme8vz4pHEZ0MtqGQZ7OCsl3Pnz5q44Z7Vd
cwN5+limQGN0dg55kYgbx+pOm0TRi5u9iAHMdlLojxD9e29AeGpRijeaWfm6ZuRk
MEQrBJMFkhm4BaOuZ8+lcmaso1SxsfdQnlEnwXBVnjt2uoqy/G14wGPxye+gb3tL
kUqBhB+DNH8RMO6Sgu+DDTsLT2vx7w7MV7XMQorBD6g4nvIxdl5OR13sI0Yo+gnt
RF6BlM7eShMrx9aYx9Xr97F9XuBH8tIOKzpSqPK+O/cevJVVu6IwSU8VyPW2o0Rr
rKCwS04vrYSwkfpvNgChNHSqhk08NKcBIQD4sLvrMZpp70OyGXgMTvryUxjzgejA
Tb1Woep3gYk=
=Q3sT
-----END PGP SIGNATURE-----
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Environment Whitelisting

[Brian Harring]

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

On Mon, Aug 22, 2005 at 06:36:03PM -0400, Alec Warner wrote:
> I'm kinda with genone on implementing both ( since they are similar ).
> If it's decided that blacklisting is easier to maintain, I can always
> make up my own whitelist for pkg-foo and apply it and if it works submit
> it as a bug ( or even some other whitelist database? ) and thus can
> gaurentee that my package was built 'correctly'(TM).  I think this would
> be important in fex, an enterprise distribution type deal where the
> build env is important to some.  Put the whitelists in the tree and have
> them --excluded by default, so only the users that use them have to
> downlaod them.
Sticking Yet Another File In Profiles (hence forth known as yafip 
since it comes up a lot :) is a quick fix, but forces anyone trying to 
do remote repo's to add hacks to expose that information; effectively 
requiring two querying modes for the repo, which doesn't seem clean.

If it goes anyways, profile would get my vote- base profile exists for 
spreading settings like this throughout all profiles also; profile and 
repo are seperated entities, as such the repo implementation doesn't 
get muddied up, just requires extra keys pulled for profile 
implementation, which is what it's designed for anyways.
~harring

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

Re: [gentoo-portage-dev] Profiles [ was Environmental Whitelisting ]

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Harring wrote:
> On Mon, Aug 22, 2005 at 06:36:03PM -0400, Alec Warner wrote:
> 
>>I'm kinda with genone on implementing both ( since they are similar ).
>>If it's decided that blacklisting is easier to maintain, I can always
>>make up my own whitelist for pkg-foo and apply it and if it works submit
>>it as a bug ( or even some other whitelist database? ) and thus can
>>gaurentee that my package was built 'correctly'(TM).  I think this would
>>be important in fex, an enterprise distribution type deal where the
>>build env is important to some.  Put the whitelists in the tree and have
>>them --excluded by default, so only the users that use them have to
>>downlaod them.
> 
> Sticking Yet Another File In Profiles (hence forth known as yafip 
> since it comes up a lot :) is a quick fix, but forces anyone trying to 
> do remote repo's to add hacks to expose that information; effectively 
> requiring two querying modes for the repo, which doesn't seem clean.
> 
> If it goes anyways, profile would get my vote- base profile exists for 
> spreading settings like this throughout all profiles also; profile and 
> repo are seperated entities, as such the repo implementation doesn't 
> get muddied up, just requires extra keys pulled for profile 
> implementation, which is what it's designed for anyways.
> ~harring

Hijacking the thread for a moment, has anyone looked into the profiles
redesign/rewrite/  syndication from web -> storage, flatfiles -> DMBS,
etc...It will need to be abstracted just the same as everything
else...Or they should be ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQwpZRmzglR5RwbyYAQJkPg//aisGvUvmh6f6XRXxIyydhaX/ec6ZpCg6
h+o7pcENYZDLO8W/SbLDOCvHsULAO0aPhK8cKGxiD2bDb/jD2Qi/2g7QxcCWjcxT
wzE1WyTGeTTlGLeR2GnGt+ZFvrZczuTKvy29fkPnXYZRWl31rFDlm2TaRD4ArNAt
3QGIJIBSAw1xRrg1T66ovKn8Ilwzw+nyvWVwV8jEB6fxo5gOtSr1pUOLqWO8FnVR
Pz0uPoVCn+OSQQRttmPaHhihDGIRnWsT58RcNZP8n/4cFqgGGpQ9wkXY/9QRhCFs
SKFpSYQY42xOH1th1hXrAQvUfXqEjALVBXLRm/aWadnGcpzySEL/p14zSMz2hXux
tBkIoosFSaOyudFD6hwAIznBAzqt61hAOvFGpFcQdUenyuh+bRR1wnKkgz6rSG9v
VB4rs+ZW12Q2QGjOkfhx06XvsoQUpEwAaEH1/kvV/7t/Kz1YhFP/01I9eVT0Zzvn
klV/AhrCHml319yu1WPuWjMGL9E5LLMC7FNgBzfiWSxk7WBsACSdm+EXcyFzDPvs
A6vS6mLouPMgbch5VT/8sw+KWfEGqTRwxfu0Gw+mzj3atNYmByoNPgVg2mQYatJs
+atlR/hRuTTnv0WV7dqtNLFuLCqBfoJTXPOuc5qsTSJaYGyAnZREk+kttF7TyTG8
qMdx+2/zvBc=
=c82h
-----END PGP SIGNATURE-----
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Environment Whitelisting

[Jason Stubbs]

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

On Tuesday 23 August 2005 06:40, Brian Harring wrote:
> On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote:
> > Theoretical discussions about this are pointless IMO without
> > numbers/facts to back things up.
>
> I'd posit theroetical discussions about this are pointless without
> getting ebuild dev's to give a yay/nay on whether they want it or not;
> not much for trying to force it down their throats if they don't want
> it (more work, essentially).

I don't really see what it has to do with ebuild devs... We're talking about 
the user's environment leaking into the portage build environment, no? 
Environment vars used by ebuilds can/should be set by users in a portage 
configuration file rather than being added to the environment. The only 
issue i see here is user customizations - fex, a hypothetical colorgcc that 
gets its config info from the env.

-- 
Jason Stubbs

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

Re: [gentoo-portage-dev] Environment Whitelisting

[Brian Harring]

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

On Tue, Aug 23, 2005 at 08:28:08AM +0900, Jason Stubbs wrote:
> On Tuesday 23 August 2005 06:40, Brian Harring wrote:
> > On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote:
> > > Theoretical discussions about this are pointless IMO without
> > > numbers/facts to back things up.
> >
> > I'd posit theroetical discussions about this are pointless without
> > getting ebuild dev's to give a yay/nay on whether they want it or not;
> > not much for trying to force it down their throats if they don't want
> > it (more work, essentially).
> 
> I don't really see what it has to do with ebuild devs... We're talking about 
> the user's environment leaking into the portage build environment, no? 
> Environment vars used by ebuilds can/should be set by users in a portage 
> configuration file rather than being added to the environment. The only 
> issue i see here is user customizations - fex, a hypothetical colorgcc that 
> gets its config info from the env.
Ixnaying user env leaking in will lead to bugs where ebuilds *allow* 
for that, along with pissed off ebuild devs if they've not been made 
aware of it oncoming.

Hell, they may not even agree on the deterministic bit re: env; this 
would explicitly block developers from fooling with autotool vars 
(WANT_AUTOMAKE fex) for testing without mangling the ebuild.

So yeah, I'm trying to ensure we're not screamed at for deploying what 
(imo) is a good change, but may piss people off if it's not stated up 
front (akin to glep 33).
~harring

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

Re: [gentoo-portage-dev] Environment Whitelisting

[Jason Stubbs]

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

On Tuesday 23 August 2005 08:56, Brian Harring wrote:
> On Tue, Aug 23, 2005 at 08:28:08AM +0900, Jason Stubbs wrote:
> > On Tuesday 23 August 2005 06:40, Brian Harring wrote:
> > > On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote:
> > > > Theoretical discussions about this are pointless IMO without
> > > > numbers/facts to back things up.
> > >
> > > I'd posit theroetical discussions about this are pointless without
> > > getting ebuild dev's to give a yay/nay on whether they want it or
> > > not; not much for trying to force it down their throats if they don't
> > > want it (more work, essentially).
> >
> > I don't really see what it has to do with ebuild devs... We're talking
> > about the user's environment leaking into the portage build
> > environment, no? Environment vars used by ebuilds can/should be set by
> > users in a portage configuration file rather than being added to the
> > environment. The only issue i see here is user customizations - fex, a
> > hypothetical colorgcc that gets its config info from the env.
>
> Ixnaying user env leaking in will lead to bugs where ebuilds *allow*
> for that, along with pissed off ebuild devs if they've not been made
> aware of it oncoming.
>
> Hell, they may not even agree on the deterministic bit re: env; this
> would explicitly block developers from fooling with autotool vars
> (WANT_AUTOMAKE fex) for testing without mangling the ebuild.
>
> So yeah, I'm trying to ensure we're not screamed at for deploying what
> (imo) is a good change, but may piss people off if it's not stated up
> front (akin to glep 33).

I think possibly our terminology is getting confused though.. Let's label 
stuff. I'll call the "build environment" (BE) that which an ebuild executes 
in, and the "calling environment" (CE) that which emerge (or whatever tool) 
was ran from.

I see your point about the CE getting passed down to the BE for dev 
purposes. However, I don't see why stuff in the CE should be passed down to 
the BE in general. Aren't we trying to move away from users configuring 
stuff in the CE? How's about leaving the CE out of variable cascading 
altogether by default and just make it an option feature? :)

With regards to white/blacklisting, I don't mind so much either way if the 
CE is not passed by default. However, I think that all portage-specific 
variables (such as FEATURES or PORTDIR) should not get passed down unless 
they really should be. I guess that sounds like blacklisting.

-- 
Jason Stubbs

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

Re: [gentoo-portage-dev] Environment Whitelisting

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Stubbs wrote:
> On Tuesday 23 August 2005 06:40, Brian Harring wrote:
> 
>>On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote:
>>
>>>Theoretical discussions about this are pointless IMO without
>>>numbers/facts to back things up.
>>
>>I'd posit theroetical discussions about this are pointless without
>>getting ebuild dev's to give a yay/nay on whether they want it or not;
>>not much for trying to force it down their throats if they don't want
>>it (more work, essentially).
> 
> 
> I don't really see what it has to do with ebuild devs... We're talking about 
> the user's environment leaking into the portage build environment, no? 
> Environment vars used by ebuilds can/should be set by users in a portage 
> configuration file rather than being added to the environment. The only 
> issue i see here is user customizations - fex, a hypothetical colorgcc that 
> gets its config info from the env.
> 

Because ebuild devs are the ones doing the maintainance of the
{black,white}lists, and they are the ones who have to futz with them
whenever they want to do funny things.  It's their work to keep things
running smoothly, not ours.  Who wants to foist work on people who
aren't willing to do it?  The lists will just get old and crappy and the
whole system would be useless.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQwptf2zglR5RwbyYAQIhgg//emfko2JdLiibeQc0pmTTY/quD61v6sy0
y5C/VD/EUHSul2ba1so5ZzzXxWMzmwFPdIMRUulisQ2Y7TKRxBTrUu/djQe/tx0p
cGaQekSdLCU0F+4HC2A7bI2kQA1/CspFjETSojyouMXrcM+AMvevIr6+Odf7jfJp
RDkcgzMW14CNjd+nKJ36J/h9Rs17KA5ZU4lnK9MKN9w5wEsw7QtXPyuPgasZ7jx3
H6aOm8WGEP7jiBe/LMYCwaYbb0kElFqUXp/3VyXmuU02vLCHFrTV7oz3LiwfcTi9
MTgwmyzrcBHuMlA5dIxeXGX2icl46KXvsYOhszRjREuUp4F3EqnT+pdwNPqhxCeR
KXbJt8hofYGCvwahoAaxEz6sfv0Jvs8t8BOfDC2FNXYwgSxq2RFRvC2t1iWr+I2f
Phw4m6qZ7QDlz0bgE/Pdnm0TLPolf7+KsoANdJa3lnSXwqrJHR0LhTPJ6GoX82Jw
4woYto47hstVcUWX18dHIQ01ouXgku0++p8eNhLe4B5oKn1Pf5u/tkvdgTS3t/Tb
mrcq+uDy1AWY+lA+W2im/Bbkq9DI551dtlXS4zLO/GX+rs+h+EgtgE0bkwb3f5Q7
mkF58rO6EDBRywvMYxcOzKfHF6f4ty3OQ0i1DrdqIoMFjrCDnNfAODI7YZNF/BWB
D0/VyCA4E2Q=
=q9+h
-----END PGP SIGNATURE-----
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Environment Whitelisting

[Kristian Benoit]

On Tue, 2005-08-23 at 08:28 +0900, Jason Stubbs wrote:
> On Tuesday 23 August 2005 06:40, Brian Harring wrote:
> > On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote:
> > > Theoretical discussions about this are pointless IMO without
> > > numbers/facts to back things up.
> >
> > I'd posit theroetical discussions about this are pointless without
> > getting ebuild dev's to give a yay/nay on whether they want it or not;
> > not much for trying to force it down their throats if they don't want
> > it (more work, essentially).
> 
> I don't really see what it has to do with ebuild devs... We're talking about 
> the user's environment leaking into the portage build environment, no? 
> Environment vars used by ebuilds can/should be set by users in a portage 
> configuration file rather than being added to the environment. The only 
> issue i see here is user customizations - fex, a hypothetical colorgcc that 
> gets its config info from the env.

That's exactly what I was saying, we filter the environment to let only
portage's variables (USE, FEATURE, ...) pass through. But the user may
specify a bunch variables that will pass through. Ex:

$ FOO=bar USE=X emerge vim

vim's ebuild wont see the variable FOO but will see USE.
But if someone run:

$ PORTAGE_USER_VARS="FOO" FOO=bar USE=X emerge vim

The ebuild will see both FOO and USE.
But suppose that foo has 10 depencies and I want FOO to be defined only
for vim. I can write /etc/portage/package.env.d/app-editors/vim:

BAR=$TMP/bar
FOO=$BAR/foo
PORTAGE_USER_VARS="$PORTAGE_USER_VARS FOO"

Then if I run:

$ TMP=/home/me USE=X emerge vim

The ebuild will see both USE and FOO but not BAR and TMP.

It could also be only one file (/etc/portage/package.env):

app-editors/vim  "FOO BAR"
app-...

then FOO and BAR will be defined when running the ebuild if defined in
the env.

Or:

app-editors/vim	 'FOO=bar BAR="bla bla"'


Which one do you prefer ?


I think this give more freedom to the user than white/blacklisting and
provide clean environment to the ebuilds. Plus no need for the package
managers to manage white/blacklist.


Kristian

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

Re: [gentoo-portage-dev] Environment Whitelisting

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kristian Benoit wrote:
> On Tue, 2005-08-23 at 08:28 +0900, Jason Stubbs wrote:
> 
>>On Tuesday 23 August 2005 06:40, Brian Harring wrote:
>>
>>>On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote:
>>>
>>>>Theoretical discussions about this are pointless IMO without
>>>>numbers/facts to back things up.
>>>
>>>I'd posit theroetical discussions about this are pointless without
>>>getting ebuild dev's to give a yay/nay on whether they want it or not;
>>>not much for trying to force it down their throats if they don't want
>>>it (more work, essentially).
>>
>>I don't really see what it has to do with ebuild devs... We're talking about 
>>the user's environment leaking into the portage build environment, no? 
>>Environment vars used by ebuilds can/should be set by users in a portage 
>>configuration file rather than being added to the environment. The only 
>>issue i see here is user customizations - fex, a hypothetical colorgcc that 
>>gets its config info from the env.
> 
> 
> That's exactly what I was saying, we filter the environment to let only
> portage's variables (USE, FEATURE, ...) pass through. But the user may
> specify a bunch variables that will pass through. Ex:
> 
> $ FOO=bar USE=X emerge vim
> 
> vim's ebuild wont see the variable FOO but will see USE.
> But if someone run:
> 
> $ PORTAGE_USER_VARS="FOO" FOO=bar USE=X emerge vim
> 
> The ebuild will see both FOO and USE.
> But suppose that foo has 10 depencies and I want FOO to be defined only
> for vim. I can write /etc/portage/package.env.d/app-editors/vim:
> 
> BAR=$TMP/bar
> FOO=$BAR/foo
> PORTAGE_USER_VARS="$PORTAGE_USER_VARS FOO"
> 
> Then if I run:
> 
> $ TMP=/home/me USE=X emerge vim
> 
> The ebuild will see both USE and FOO but not BAR and TMP.
> 
> It could also be only one file (/etc/portage/package.env):
> 
> app-editors/vim  "FOO BAR"
> app-...
> 
> then FOO and BAR will be defined when running the ebuild if defined in
> the env.
> 
> Or:
> 
> app-editors/vim	 'FOO=bar BAR="bla bla"'
> 
> 
> Which one do you prefer ?
> 
> 
> I think this give more freedom to the user than white/blacklisting and
> provide clean environment to the ebuilds. Plus no need for the package
> managers to manage white/blacklist.
> 
> 
> Kristian
> 

In either kind of list editing of this type would have to be allowed.
However black/whitelists are still necessary IMHO.  You don't know what
vars destroy builds, but the maintainer does.  Why wouldn't you want him
blocking out a variable that is KNOWN to break a build?  Modifying the
API to print things blacklisted would be easy and if the maintainer has
blacklisted something important for you you can always remove it via
some setting ( /etc/portage or otherwise ).

Alec Warner (antarus)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQwqaq2zglR5RwbyYAQKz+g//TQTaZCV+oXw/R6tLzSQhe0qhZcxDfSMz
Kdy8q6FHsXxwJ4QSVudszQnvmLBKVlSXXGHMFAmbOHq/ATyesnFG+bGjRPHxiPfV
ZW+PDRNJ/1LvInMVa6LyhjrSyKVz3XlqPIfCNoo9AdWM8s38lonG8zapsolkLs2b
sA5v40xQVCA1PhvYMdCOeNdfK2PJSqh9wLj8NTdSJOqffZWBpLGd50TFgLVSXbhd
u5hCoXK/kivWJ9pYCBgKwffEC78OOHSjmhkslxQR5luVJcn5ijs8P2fQUbPM5YGS
2BfGDRthj0lNTlo2Jt4QhnjkdQTPXMzRAbhLuVWsYYJl6+1ngMgWkM2jKV9P1WuE
gilDrAuU83pl4vRX2Gh5jtYlzDScRQqe/vwzKaXXjEjQNfwCUmhh82tDgGSDmSo7
bMLrDGA6xj7ptqMLDOqewpwVvqCR2FQ9Qq/ZgQidmnjNcX83wd1cJZBKyszP5KIG
YMztpKAb9TsGgdfHo0yV694vVoTlpBQ9B2wv+47FJReSw0bCWvUbqIsuAOGcGJzk
8HczKv/ySWc20pm6muBLrC63HAcGa0siE1ZQLTmyCLfN7G6yeFrK4Si9e5qQzF05
QVQCXLORq84v2cLJgiEkhysYEMFDSYkYBPZJ831eWuab/yrXAdT7IvoEPDmnRsM2
0ocP3wXhSGA=
=t2n9
-----END PGP SIGNATURE-----
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Environment Whitelisting

[Kristian Benoit]

On Mon, 2005-08-22 at 23:40 -0400, Alec Warner wrote:
> Why wouldn't you want him blocking out a variable that is KNOWN to
> break a build?

I could be trying to fix that up. It might usually break, but one could
have a special setting like uclibc. The breakage might come from an
external lib that one hacked and it doesnt break cause of his hack.

You probably can find a lot of other situations.

But as you said:

> you can always remove it via some setting ( /etc/portage or
> otherwise ).

Black/whitelisting could allow you to specify vars to go through.

Kristian

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