Requests: option to disable .netrc

Created on 12 Sep 2015  路  16Comments  路  Source: psf/requests

I don't want my applications to read .netrc files, because they are inherently insecure.

I know there's (undocumented) trust_env=False, but it also turns off support for *_proxy environment variables.

Please add a separate option to disable .netrc support.

Most helpful comment

I'm not sure why this was closed. The only rationale I had so far was that trust_env can be used to disable this, but the problem with that is that is also disables proxy configuration... not just the .netrc...

or should I send a PR to document my NullAuth workaround?

All 16 comments

@jwilk This is certainly a thing we could do. However, it's a bizarrely application specific fix that will not actually help in a lot of cases because applications that use requests will need to opt-in to that functionality. This means they need to know enough to do that, which is not likely.

Really from a security perspective we should switch to disable netrc auth by default (a change that would need to wait until a 3.0.0 release because it's backwards incompatible, though potentially something worth doing).

In the short term, you will get more security either by not using ~/.netrc files at all (thereby removing the source of the vulnerability altogether) or by constructing AppArmor profiles that limit access to the file to those applications you have pre-authorized to use it.

@sigmavirus24 For the longer term, I'm open to swapping our default here, which is arguably somewhat insecure, though I also just think people shouldn't be writing their passwords down anywhere at all, at least not in plaintext.

@Lukasa isn't there already an open issue for turning auto-loading of netrc off by default for 3.0.0? I thought we were in agreement on this already. I've never once thought this was a good idea but we haven't had opportunity to break this behaviour previously.

I'd also be okay moving get_netrc_auth (or whatever the function is actually called) into the auth module and documenting it publicly.

Quite possibly.

Moving get_netrc_auth to auth could work, but it hurts the redirec case unless we turn it into some fancier kind of auth handler.

NetrcAuth class then?

Then we can leave the function in utils and have the auth handler do the hard work

Suits me. Do we need the ability to have multiple auth handlers?

to work around this, i added a way to disable authentication:

class NullAuth(requests.auth.AuthBase):
    '''force requests to ignore the ``.netrc``

    Some sites do not support regular authentication, but we still
    want to store credentials in the ``.netrc`` file and submit them
    as form elements. Without this, requests would otherwise use the
    .netrc which leads, on some sites, to a 401 error.

    Use with::

        requests.get(url, auth=NullAuth())
    '''

    def __call__(self, r):
        return r

Could that be added in an earlier release? It won't break API...

@anarcat That works fine as a user-specific workaround, but we won't ship it in requests itself.

FWIW, you can disable this functionality today with trust_env. Due to strong opinions I had when I started this project, its default is set to true.

s = requests.session()
s.trust_env = False

r = s.get(...)

The idea was that .netrc is a well-adopted standard that tools like curl utilize automatically, therefore I wanted Requests to honor it automatically as well. If a user was concerned with that security implication, they shouldn't trust their environment at all, and I provided an option for them to do so.

Setting trust_env to false may be a good next step. It's one of those things, though, that if it doesn't work automatically out-of-the-box, then there's really no point in having the functionality at all.

On 2016-01-31 04:05:17, Kenneth Reitz wrote:

FWIW, you can disable this functionality today with trust_env. Due to strong opinions I had when I started this project, it's default is set to true.

s = requests.Session()
s.trust_env = False

r = s.get(...)

The idea was that .netrc is a well-adopted standard that tools like curl utilize automatically, therefore I wanted Requests to honor it automatically as well. If a user was concerned with that security implication, they shouldn't trust their environment at all, and I provided an option for them to do so.

Setting trust_env to false may be a good next step. It's one of those things, though, that if it doesn't work automatically out-of-the-box, then there's really no point in having the functionality at all.

The problem with trust_env is that it works too broadly. For example, it
also disables proxy configuration... "and similar", according to the
docs. It should be made clear what, exactly, is disabled there and
ideally, those bits should be possible to disable one at a time.

And I think it's fine that requests support .netrc by default, it makes
perfect sense. It should just be easier to disable it.

A.

La d茅mocratie r茅elle se d茅finit d'abord et avant tout par la
participation massive des citoyens 脿 la gestion des affaires de la cit茅.
Elle est directe et participative. Elle trouve son expression la plus
authentique dans l'assembl茅e populaire et le dialogue permanent sur
l'organisation de la vie en commun. - De la servitude moderne

i got the same problem, Is there way to solve it

s = requests.session()
s.trust_env = False

i will use proxy info, whether not it will influence it

If you set the proxies from environment variables then yes.

so , finally, I detele the .netrc

I'm not sure why this was closed. The only rationale I had so far was that trust_env can be used to disable this, but the problem with that is that is also disables proxy configuration... not just the .netrc...

or should I send a PR to document my NullAuth workaround?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

cnicodeme picture cnicodeme  路  3Comments

thadeusb picture thadeusb  路  3Comments

jakul picture jakul  路  3Comments

ReimarBauer picture ReimarBauer  路  4Comments

mitar picture mitar  路  4Comments