On Tue, May 26, 2020 at 9:46 AM Zac Medico <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>> 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 > >
