Use NETRC environment variable

[berthin]

Feature or enhancement

Proposal:

Hi,

I'd like to add support to the NETRC environment variable as documented in GNU inetuils v2.6 (https://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-file.html). Other tools and libraries are already supporting that envvar and I think it would be nice to aligned as well in that regard.

Supporting the envvar should be as simple as changing:

cpython/Lib/netrc.py

Line 70 in 7c43615

file = os.path.join(os.path.expanduser("~"), ".netrc")

with

file = os.environ.get("NETRC", None) or os.path.join(os.path.expanduser("~"), ".netrc")

Best regards,
Berthin

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs

• gh-135788: Support NETRC environment variable in netrc #135802

[picnixz]

FTR, it's supported in (pip) pypa/pip#11023 and requests (psf/requests#5643) as well as httpx (https://www.python-httpx.org/advanced/authentication/#netrc-authentication).

I think it's a legitimate addition, though any PR doing it needs tests & docs.

[berthin]

FTR, it's supported in (pip) pypa/pip#11023 and requests (psf/requests#5643) as well as httpx (https://www.python-httpx.org/advanced/authentication/#netrc-authentication).

I think it's a legitimate addition, though any PR doing it needs tests & docs.

Cool, I can work on this.

[picnixz]

Sure! but please read https://devguide.python.org/getting-started/pull-request-lifecycle/ first so to avoid surprises! TiA

[cmaloney]

I don't think getting the path from an environment variable by default in CPython netrc is good from a security perspective as netrc underlies multiple http libraries which explicitly implement a trust_env[0] option to disable getting configuration from environment variables. They generally do this in their code, then pass a path to netrc from my reading, and CPython changing under the hood to read an env var potentially could bypass that protection. An opt-in implementation I think would allow their security design and be good to add to CPython.

I do think it's useful to have environment variable support, and it would be nice to reduce the boiler plate that seems to be getting added to the multiple http client libraries, but doing so I think needs to be opt-in (ex. allow_env=True parameter, a new entrypoint, or some other bike shed).

[0] Ones I looked at:

• requests https://requests.readthedocs.io/en/latest/user/authentication/#netrc-authentication which defaults to True, some more background: option to disable .netrc psf/requests#2773
• aiohttp https://docs.aiohttp.org/en/stable/client_advanced.html#proxy-support which defaults to False
• httpx https://www.python-httpx.org/environment_variables/ which defaults to True

[picnixz]

I don't think getting the path from an environment variable by default in CPython netrc is good from a security perspective as netrc underlies multiple http libraries which explicitly implement a trust_env

Hum, in this case I think we shouldn't do it by default as well on our side. I'm ok with with using a boolean or an alternative constructor.

[berthin]

I don't think getting the path from an environment variable by default in CPython netrc is good from a security perspective as netrc underlies multiple http libraries which explicitly implement a trust_env

Hum, in this case I think we shouldn't do it by default as well on our side. I'm ok with with using a boolean or an alternative constructor.

Interesting point. I don't mind adding that. But before, what do you think about the following:

a) The documentation must clearly state what the scope oftrust_env will be. It might be a bit confusing for instance to set trust_env=False and then expect os.expanduser to work, because that can rely in the HOME envvar (https://github.com/python/cpython/blob/main/Lib/posixpath.py#L244).
b) The difference between netrc.trust_env=... and netrc.netrc(trust_env=...) is the scope. The former is module level, while the later is function level. I personally think that function level is safer between the two.

[cmaloney]

a) Definitely needs clear/concise documentation (want to avoid security FUD); overall the feature (NETRC env var support in CPython netrc) should make it easier for more community/libraries to add support. I have a slight preference for a new name / flag as trust_env is already defined by multiple different Python libraries with different defaults and meanings, not sure CPython adding another would make things easier to understand.
b) I like function level for clearer config/control flow. I'm generally a fan of reducing non-constant global state.

[berthin]

a) Definitely needs clear/concise documentation (want to avoid security FUD); overall the feature (NETRC env var support in CPython netrc) should make it easier for more community/libraries to add support. I have a slight preference for a new name / flag as trust_env is already defined by multiple different Python libraries with different defaults and meanings, not sure CPython adding another would make things easier to understand. b) I like function level for clearer config/control flow. I'm generally a fan of reducing non-constant global state.

An alternative could be to name the option as trust_netrc_env so it leaves no room for misunderstandings. However, maybe this is a bigger discussion for the library maintainers?

[cmaloney]

To me at least (not a CPython core dev), your choice if you want to do larger library maintainer reach out/coordination. Would likely mean get much more precisely what libraries want/will use but also requires a lot more time/effort. This is a new feature so I think currently heading towards Python 3.15 which means do have a bit of time to get things done (feature freeze for 3.15 is with beta1 on 2026-05-05 per PEP-790).

[berthin]

@picnixz do you think you can make a judgement call and decide if #135788 (comment) is acceptable? or would you like (me) to open(start) the discussion with other library maintainers to decide if there could be a convention to enable/disable the use of envvars.