On 5/26/20 10:16 AM, Alec Warner wrote: > On Tue, May 26, 2020 at 9:46 AM Zac Medico <zmed...@gentoo.org > <mailto:zmed...@gentoo.org>> wrote: > > On 5/26/20 1:43 AM, Alec Warner wrote: > > On Mon, May 25, 2020 at 9:34 PM Zac Medico <zmed...@gentoo.org > <mailto:zmed...@gentoo.org> > > <mailto:zmed...@gentoo.org <mailto:zmed...@gentoo.org>>> 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
signature.asc
Description: OpenPGP digital signature
