https://pantsbuild.org/ logo
#general
Title
# general
e

enough-analyst-54434

05/31/2022, 4:21 PM
Pants-powered open-source projects are a bit of a pain to hack on in a corporate environment as brought to light here: https://github.com/pantsbuild/pants/issues/15675
In short, the open source project needs to anticipate that its users might be behind proxies or those users need to hack up their ~/.pants.rc to let proxy env vars through.
Neither seems awesome.
Does it make sense to punch holes for those env vars by default? They should not affect cache hit rates meaningfully, since those are almost always uniform env vars in an org.
Probably best to opine in the github issue if this interests you.
a

ancient-vegetable-10556

05/31/2022, 4:34 PM
@enough-analyst-54434 yes, we should probably pass-through proxy envvars, or at least make it easier ask for them to be passed through. I’d be concerned about remote-caching processes that have been run with proxy envvars set though
(imagining a world where two different corporate environments use an IP address for their proxy and they happen to MITM pertinent URLs in some way)
e

enough-analyst-54434

05/31/2022, 4:37 PM
So the scenario you're concerned about is an open source project configured with remote caching - say via Toolchain - like Pants is in CI, but also for open source devs, and then a dev behind a corporate firewall does what?
I guess I'm not seeing how any env var sec issues are new in this scenario. The only thing new is punching a hole by default. If there has been / is a sec issue with proxy env vars, we've already got that issues afaict.
a

ancient-vegetable-10556

05/31/2022, 4:38 PM
checks out.
My concern was cache contamination around two different corporate users poisoning the cache with differently-behaving proxy servers with the same envvar settings. If we’ve already got issues there, then this is a very unlikely theoretical manifestation of that issue, and we shouldn’t trouble ourselves with it
2 Views