homebrew venv with tls inspection

[adam-moss]

Hi,

Unfortunately our operating environment mandates TLS inspection and, irrespective of personal feelings on the matter, it means we have to inject an additional certificate into the chain as well as reference our own cacheing proxy:

~ % cat .config/pip/pip.conf 
[global]
cert = /etc/ssl/certs/ca-certs.pem
index-url = https://fqdn/repository/pypi/simple

~ %

We've started to experience issues when installing certain homebrew formula, e.g. awscli, not picking up the user's pip.conf and thusly failing due to a mismatch in the SSL certificates.

If I brew install --debug awscli and then chose option (5) shell when it fails, I can see pip3 config list hasn't inherited the settings.

Is this expected behaviour or is there a workaround for this issue?

Thanks!

[Bo98]

The brew build environment overrides $HOME so that is possibly why. Does the global config /Library/Application Support/pip/pip.conf work?

[Bo98]

Most environment variables are intentionally ignored by brew - user configs and environment variables can very often change the build in a way that breaks it so we do not support them. And it's extremely rare that someone actually ends up needing them.

Unfortunately, there is no workaround I am aware of. If the pip.conf changes are what your sysadmin expects you to do, I think you have an argument you can make for them to make those changes on a global level (which I think should work - but I have not tested it). But that's all I can suggest for now.

[adam-moss]

Thanks.

Yes, they are willing to do that, if the developers are willing to go via JAMF rather than homebrew, thus starting a vicious cycle of re-authentication with 2fa, and thusly context switching and a poor user experience for the developers. I'm trying to simplify things as much as possible.

I'm wondering if I could contribute something like an env var of HOMEBREW_PIP_CONFIG_FILE but I guess the use case is so niche it wouldn't be something you'd really look to adopt.

Thanks for your assistance 👍

[Bo98]

I'm trying to simplify things as much as possible.

I understand. Sometimes these IT environments can be frustrating.

I guess the use case is so niche it wouldn't be something you'd really look to adopt

I discussed PIP_CERT and PIP_INDEX_URL a bit (I don't think a general PIP_CONFIG_FILE is a good idea) with a couple other maintainers and the consensus was indeed that it was a bit niche.

As with all features, if there's a wider use case then we're happy to hear it. It's a question we ask for all new features: "How will the feature be relevant to at least 90% of Homebrew users?"

[adam-moss]

Yeah, this is definitely more an "enterprise" feature than an end user one, and of course somewhat ironic in context.

I'll have a ponder. If I can track it down in the code base it may be something we could patch locally, if it isn't too gnarly I can submit it and you can chose to accept it or not, but at least there'll be a reference lying around to it 👍

Thanks again, I appreciate it 💯

[BenjamenMeyer]

@Bo98 what about using $(brew --prefix)/etc/pip.conf (or something else under $(brew --prefix) as an option? If it exists use it like /Library/Application Support/pip/pip.conf?

Also, how does one use HOMEBREW_PIP_INDEX_URL? I'm trying it but with glib it does seem to be recognized. I'm thinking that formula may be broken with respect to its Python usage as everything I'm trying is not working even though its documented with Homebrew.

Like @adam-moss , my options are limited on this system as it is heavily regulated by our IT and security teams so at least for the moment /Library/Application Support/pip/pip.conf isn't an option. Trying to find a work-around; any advise even on where to look in the code so I can contribute a PR would be appreciated (not a ruby dev, but still willing to give it a try).

[MikeMcQuaid]

Tell your corporate environment that you need to use Homebrew to do your job and they need to make the changes here, not a volunteer-run open source project.

[adam-moss]

Mike

I'm sure you didn't mean that to come across the way it did, but that response is roughly the equivalent of me responding with "how about the volunteer-run open source project respects the user's configuration, rather inject its own?"

There are two sides to every coin here, and if the answer to my

Is this expected behaviour or is there a workaround for this issue?

Is Yes, and No, respectively, that's fine, but lets be civil about it please.

If you think that was unreasonable to ask in the first place, well then I'm sorry to have wasted your time, but having spent a chunk of time scouring the docs before asking I couldn't find the answer 🙄

[MikeMcQuaid]

I'm sure you didn't mean that to come across the way it did, but that response is roughly the equivalent of me responding with "how about the volunteer-run open source project respects the user's configuration, rather inject its own?"

The difference is: you're asking for help from the open source project's community and we're not asking you or your organisation to help us.

Is this expected behaviour or is there a workaround for this issue?

Yes, expected behaviour, no workaround.

If you think that was unreasonable to ask in the first place, well then I'm sorry to have wasted your time, but having spent a chunk of time scouring the docs before asking I couldn't find the answer 🙄

I don't think it was unreasonable but I'd suggest that it's less productive than what I suggested.

I'm not sure how asking me to be civil the 🙄 emoji go together, though.

[adam-moss]

The difference is: you're asking for help from the open source project's community and we're not asking you or your organisation to help us.

Ok, I can see where you're coming from here, I do appreciate answering queries takes time. I also appreciate you probably get a load of queries that are already answered in the docs, discussions, and issues that aren't searched first. It can be quite frustrating.

And you're right, you've never asked anything from me or my organisation, yet we have contributed.

Yes, expected behaviour, no workaround.

Thank you for the clarification.

I don't think it was unreasonable but I'd suggest that it's less productive than what I suggested.

Unfortunately I have explored that option many times previously, the idea of inspection being a good thing drives me nuts. Thankfully with the changes to TLS that's coming in this will be all but impossible in future, but we're stuck with it for now.

I'm not sure how asking me to be civil the 🙄 emoji go together, though.

That's a fair shout, I apologise 👍

[MikeMcQuaid]

That's a fair shout, I apologise 👍

Thanks, much appreciated, no hard feelings ❤️