New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pip should not warn wrt https on localhost #1456

Closed
hpk42 opened this Issue Jan 10, 2014 · 19 comments

Comments

Projects
None yet
9 participants
@hpk42

hpk42 commented Jan 10, 2014

Currently, pip warns if https is not used. This warning should be disabled when using localhost. People using for example devpi-server as a local mirror on their laptop should not be forced to setup https on localhost as it adds no extra security.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Jan 10, 2014

Member

Well they aren't forced. It's just a warning everything still works.

However there's another ticket to allow acknowledging the warning and waning fatigue is an issue to consider. So I'd say there is possibly something we want to do here.

On Jan 10, 2014, at 6:45 AM, holger krekel notifications@github.com wrote:

Currently, pip warns if https is not used. This warning should be disabled when using localhost. People using for example devpi-server as a local mirror on their laptop should not be forced to setup https on localhost as it adds no extra security.


Reply to this email directly or view it on GitHub.

Member

dstufft commented Jan 10, 2014

Well they aren't forced. It's just a warning everything still works.

However there's another ticket to allow acknowledging the warning and waning fatigue is an issue to consider. So I'd say there is possibly something we want to do here.

On Jan 10, 2014, at 6:45 AM, holger krekel notifications@github.com wrote:

Currently, pip warns if https is not used. This warning should be disabled when using localhost. People using for example devpi-server as a local mirror on their laptop should not be forced to setup https on localhost as it adds no extra security.


Reply to this email directly or view it on GitHub.

@hpk42

This comment has been minimized.

Show comment
Hide comment
@hpk42

hpk42 Jan 10, 2014

But what's the point about warning about http://localhost ? Is there any good reason to do so? Note that i am willing to do a PR to except localhost from the warning.

hpk42 commented Jan 10, 2014

But what's the point about warning about http://localhost ? Is there any good reason to do so? Note that i am willing to do a PR to except localhost from the warning.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Jan 10, 2014

Member

Sorry, to be more clear I'm not really against it. I was just saying that they aren't forced to do anything about it (There was a misconception about this on Twitter this morning due to another bug with pip 1.5 + devpi).

I'm mostly just wondering if it makes sense to just exclude localhost, or if there should be a setting of "allowed http" that just defaults to localhost hence my reference to the other ticket, which was #1313.

Member

dstufft commented Jan 10, 2014

Sorry, to be more clear I'm not really against it. I was just saying that they aren't forced to do anything about it (There was a misconception about this on Twitter this morning due to another bug with pip 1.5 + devpi).

I'm mostly just wondering if it makes sense to just exclude localhost, or if there should be a setting of "allowed http" that just defaults to localhost hence my reference to the other ticket, which was #1313.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Jan 10, 2014

Member

+1

I don't have a particular need for this feature, but as a general principle, I think we need to make sure we keep the security warnings focused and accurate, if only because we're already getting requests for "don't bother me about security risks" flags, and we don't want to fuel the thinking behind that (that pip is becoming unnecessarily fussy over security).

I cannot see any reason why http on localhost should ever be a security risk, so I think we should unconditionally exclude it from the warning. Whether we add a facility for users to add other hosts as well is less relevant.

Member

pfmoore commented Jan 10, 2014

+1

I don't have a particular need for this feature, but as a general principle, I think we need to make sure we keep the security warnings focused and accurate, if only because we're already getting requests for "don't bother me about security risks" flags, and we don't want to fuel the thinking behind that (that pip is becoming unnecessarily fussy over security).

I cannot see any reason why http on localhost should ever be a security risk, so I think we should unconditionally exclude it from the warning. Whether we add a facility for users to add other hosts as well is less relevant.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 28, 2014

Member

So my question, should we warn about insecure transport at all? We do the right thing with PyPI by default.

Member

dstufft commented Mar 28, 2014

So my question, should we warn about insecure transport at all? We do the right thing with PyPI by default.

@hpk42

This comment has been minimized.

Show comment
Hide comment
@hpk42

hpk42 Mar 28, 2014

Do you mean if we should warn about non-https on hosts other than pypi? If so i don't have a strong opinion currently.

hpk42 commented Mar 28, 2014

Do you mean if we should warn about non-https on hosts other than pypi? If so i don't have a strong opinion currently.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 28, 2014

Member

Yes

Member

dstufft commented Mar 28, 2014

Yes

@mmerickel

This comment has been minimized.

Show comment
Hide comment
@mmerickel

mmerickel Apr 14, 2014

I'm hosting devpi inside of docker and so I get the warning at http://localdocker:3141/root/pypi so the localhost exemption would not help rid myself of this warning.

mmerickel commented Apr 14, 2014

I'm hosting devpi inside of docker and so I get the warning at http://localdocker:3141/root/pypi so the localhost exemption would not help rid myself of this warning.

@jnrbsn

This comment has been minimized.

Show comment
Hide comment
@jnrbsn

jnrbsn May 3, 2014

You could do a socket.gethostbyname(hostname) and then check if the IP is private (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and allow insecure transport if it's private. Although, it would be more complicated if you wanted to do the equivalent for IPv6.

jnrbsn commented May 3, 2014

You could do a socket.gethostbyname(hostname) and then check if the IP is private (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and allow insecure transport if it's private. Although, it would be more complicated if you wanted to do the equivalent for IPv6.

@Ivoz

This comment has been minimized.

Show comment
Hide comment
@Ivoz

Ivoz May 4, 2014

Member

#1718 should help with this

Member

Ivoz commented May 4, 2014

#1718 should help with this

@DemiMarie

This comment has been minimized.

Show comment
Hide comment
@DemiMarie

DemiMarie Jul 28, 2014

Please keep the warnings for everything but localhost, at least by default. I want to know when I am getting a possibly-tampered-with package!

DemiMarie commented Jul 28, 2014

Please keep the warnings for everything but localhost, at least by default. I want to know when I am getting a possibly-tampered-with package!

@mmerickel

This comment has been minimized.

Show comment
Hide comment
@mmerickel

mmerickel Jul 28, 2014

I'd suggest some sort of trusted_hosts setting that can be specified to trust certain insecure hosts by ip range. It could default to 127.0.0.0/8.

mmerickel commented Jul 28, 2014

I'd suggest some sort of trusted_hosts setting that can be specified to trust certain insecure hosts by ip range. It could default to 127.0.0.0/8.

@Ivoz

This comment has been minimized.

Show comment
Hide comment
@Ivoz

Ivoz Aug 12, 2014

Member

Fixed by #1967, which should be in 1.6

Member

Ivoz commented Aug 12, 2014

Fixed by #1967, which should be in 1.6

@Ivoz Ivoz closed this Aug 12, 2014

@prologic

This comment has been minimized.

Show comment
Hide comment
@prologic

prologic Nov 28, 2014

Which is to be released wheN?

prologic commented Nov 28, 2014

Which is to be released wheN?

@hozn

This comment has been minimized.

Show comment
Hide comment
@hozn

hozn Feb 5, 2015

Are the server's SSL certs being validated [against some CA bundle] when https is being used? If not, then turn off the warning, because it adds zero security. If they are being validated, then the warning might be useful, especially if the site in question does actually support https. I think excluding all the "RFC" IPs would be a good idea, though; let people run internal mirrors over plain old http:// if they want to.

hozn commented Feb 5, 2015

Are the server's SSL certs being validated [against some CA bundle] when https is being used? If not, then turn off the warning, because it adds zero security. If they are being validated, then the warning might be useful, especially if the site in question does actually support https. I think excluding all the "RFC" IPs would be a good idea, though; let people run internal mirrors over plain old http:// if they want to.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Feb 5, 2015

Member

Yes they are being validated.

Member

dstufft commented Feb 5, 2015

Yes they are being validated.

@hozn

This comment has been minimized.

Show comment
Hide comment
@hozn

hozn Feb 5, 2015

Good, good :) I know that didn't used to be default python behavior, so wasn't sure if you were explicitly doing this. Yeah, I think the warning is good for people to think about if the name is resolving to a non-private IP. I haven't looked under the hood here, but netaddr makes this easy (and possibly simplifies the IPv6 case too?):

import netaddr
# <snip>
if not netaddr.IPAddress(resolved_server_ip).is_private():
  warnings.warn(...)

hozn commented Feb 5, 2015

Good, good :) I know that didn't used to be default python behavior, so wasn't sure if you were explicitly doing this. Yeah, I think the warning is good for people to think about if the name is resolving to a non-private IP. I haven't looked under the hood here, but netaddr makes this easy (and possibly simplifies the IPv6 case too?):

import netaddr
# <snip>
if not netaddr.IPAddress(resolved_server_ip).is_private():
  warnings.warn(...)
@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Feb 5, 2015

Member

We're using the same settings that Chrome does for secure origins: https://github.com/pypa/pip/blob/develop/pip/index.py#L37-L45

Member

dstufft commented Feb 5, 2015

We're using the same settings that Chrome does for secure origins: https://github.com/pypa/pip/blob/develop/pip/index.py#L37-L45

@hozn

This comment has been minimized.

Show comment
Hide comment
@hozn

hozn Feb 5, 2015

Cool, thanks for link! Yeah, if trusted-hosts works, that's sufficient for our needs anyway (running internal pypi server).

hozn commented Feb 5, 2015

Cool, thanks for link! Yeah, if trusted-hosts works, that's sufficient for our needs anyway (running internal pypi server).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment