Re: [gentoo-portage-dev] [PATCH] config.environ: delay export of A and AA (bug 720180)

[Alec Warner]

On Tue, May 26, 2020 at 9:46 AM Zac Medico <zmedico@g.o> wrote:

> On 5/26/20 1:43 AM, Alec Warner wrote:
> > On Mon, May 25, 2020 at 9:34 PM Zac Medico <zmedico@g.o
> > <mailto:zmedico@g.o>> wrote:
> >
> >     Since variables like A and AA can contain extremely large values
> which
> >     may trigger E2BIG errors during attempts to execute subprocesses,
> delay
> >     export until the last moment, and unexport when appropriate.
> >
> >
> > So I think if you want to do this because PMS says:
> >  AA should not be visible in EAPI > 3.
> >  A should only be visible in src_*, pkg_nofetch.
> >
> > That part of the patch makes sense to me. The part that is confusing to
> > me is the 'delay' part; can you explain that further? When you say
> > "delay until the last moment" what do you mean by that and what value is
> > it delivering?
>
> If we export an environment variable which contains an extremely large
> value, then there's a vulnerability in execve which causes it to fail
> with an E2BIG error. Since A and AA values can easily grow large enough
> to trigger this vulnerability, portage can protect itself from execve
> failures by delaying the export until the moment that it hands control
> to the ebuild phase.
>

> > Is it simply that we don't export these variables on the python side,
> > and we only use them in the shell portion?
>
> That's correct. Here's a test case which demonstrates the E2BIG error,
> and shows that 'export -n A' can suppress it:
>

I've run similar tests, but I'm less excited by this work around. I think
its reasonable to work toward eventually not exporting A and AA (the latter
already done in EAPIs > 3). Then when ebuilds encounter problems, we can
tell authors "Upgrade to EAPI X" (where X is >3 or >=8; in the potential
case of A.) Having a hard limit on A for EAPIs 0-7 and a hard limit on AA
for EAPIs 0-3 seems perfectly fine and we should expect authors to refactor
(as texlive did) in order to meet the existing API limitations.

Basically unless there are more practical use cases today, the delaying of
export seems like a feature no one will use and added complexity. I dunno
how large the go-mod use cases are yet; but I myself have not seen any with
this many deps.

-A


>
> $ A=$(dd if=/dev/zero bs=1M count=1 | tr '\0' ' ')
> 10+0 records in
> 10+0 records out
> 10485760 bytes (10 MB, 10 MiB) copied, 0.086557 s, 121 MB/s
> $ echo ${#A}
> 10485760
> $ export A
> $ ls
> bash: /bin/ls: Argument list too long
> $ export -n A
> $ /bin/echo hello world
> hello world


> --
> Thanks,
> Zac
>
>