Repository navigation
Use NETRC environment variable #135788
Description
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:
Line 70 in 7c43615
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
Activity
picnixz commentedon Jun 21, 2025
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 commentedon Jun 21, 2025
Cool, I can work on this.
picnixz commentedon Jun 21, 2025
Sure! but please read https://devguide.python.org/getting-started/pull-request-lifecycle/ first so to avoid surprises! TiA
cmaloney commentedon Jun 22, 2025
I don't think getting the path from an environment variable by default in CPython
netrcis good from a security perspective asnetrcunderlies multiple http libraries which explicitly implement atrust_env[0] option to disable getting configuration from environment variables. They generally do this in their code, then pass a path tonetrcfrom 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=Trueparameter, a new entrypoint, or some other bike shed).[0] Ones I looked at:
requestshttps://requests.readthedocs.io/en/latest/user/authentication/#netrc-authentication which defaults to True, some more background: option to disable .netrc psf/requests#2773aiohttphttps://docs.aiohttp.org/en/stable/client_advanced.html#proxy-support which defaults to Falsehttpxhttps://www.python-httpx.org/environment_variables/ which defaults to Truepicnixz commentedon Jun 22, 2025
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 commentedon Jun 23, 2025
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 of
trust_envwill be. It might be a bit confusing for instance to settrust_env=Falseand then expectos.expanduserto work, because that can rely in theHOMEenvvar (https://github.com/python/cpython/blob/main/Lib/posixpath.py#L244).b) The difference between
netrc.trust_env=...andnetrc.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 commentedon Jun 24, 2025
a) Definitely needs clear/concise documentation (want to avoid security FUD); overall the feature (
NETRCenv var support in CPythonnetrc) should make it easier for more community/libraries to add support. I have a slight preference for a new name / flag astrust_envis 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 commentedon Jun 25, 2025
An alternative could be to name the option as
trust_netrc_envso it leaves no room for misunderstandings. However, maybe this is a bigger discussion for the library maintainers?cmaloney commentedon Jun 25, 2025
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 commentedon Jul 4, 2025
@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.
picnixz commentedon Jul 4, 2025
I am travelling and will make a judgement call next week (soonest would be Friday). I'd like to be on my laptop for that. TiA
berthin commentedon Jul 5, 2025
Sure thanks! Safe travels!
berthin commentedon Aug 16, 2025
@picnixz, do you have time to review the discussions and give your opinion??
picnixz commentedon Aug 16, 2025
Hum I forgot and I am not available before next week. Let me assign myself this issue
picnixz commentedon Aug 20, 2025
My 2c (with me being sick so this is still a draft of my opinion):
a) when using the NETRC env. var, we should just take the path that is given as is, namely pass it as is to
open(). That's what already happens when we specifyfile=.... I think usingNETRCshould be equivalent to explicitly passfile=....b) let's avoid module's level configuration, it's usually a pain to maintain, changes when reloading, etc.
netrc.netrc(..., trust_env=True)would be cleaner and sufficient.I can suggest two approaches:
loadwhich does the expansion. Later, we can add more options from where a netrc file could be loaded for instance (e.g.,netrc.load(paths=[...])ornetrc.load(ignore=...)to prevent loading from some files.trust_envbecause I don't think it conflicts with something else. requests usestrust_envto indicate that we can/cannot use netrc, but the others usetrust_envto indicate whether environment variables are to be trusted in the given context. I'm ok with keepingtrust_envbecausetrust_netrc_envseems too verbose.