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

[Zac Medico]

On 5/26/20 10:16 AM, Alec Warner wrote:
> On Tue, May 26, 2020 at 9:46 AM Zac Medico <zmedico@g.o
> <mailto: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>
>     > <mailto: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


I'm in no rush to merge this patch. I wanted to create it as a proof of
concept, so that we'd be prepared for a future EAPI where the size of A
is practically unlimited. We only have to adjust the ___eapi_exports_A
function to have a working EAPI extension.
-- 
Thanks,
Zac