so, the list of variables which `pantsd` preserves when it starts up has grown slightly in order to attempt to capture variables used in docker auth (because the rust

docker

client code needs to consume them as environment variables, without forking a few libraries to allow for explicitly passing them). but that has proved to be a losing battle. some users are still encountering variables (likely specific to particular auth backends). i’m trying to decide between: 1. adding (yet another) option to allow folks to set which variables are preserved 2. giving up on trying to sandbox env vars in

pantsd

, and/or adjusting how we sandbox so that it only applies to python

4 fork and hopefully upstream the changes?

I fail to see how 3 would solve the arbitrary needs of some particular auth backend as such backends are not in the scope of libraries forked those env vars would still be required..?

3 implies actually using the environment variables from the

docker

subsystem when spawning docker processes (most likely). need to think about that one though, since the

docker

subsystem is currently specific to the

docker

plugin. oy.

if you do that, I don’t see why you’d have to fork libraries. if we provide env vars when spawning processes as that’s the expected interface to communicate those settings already.

the

docker

client that we use on the Rust side is in-process, and uses docker’s rest API