Unable to access packaging.python.org

[Spartan149]

Problem description

Hi there, I am trying to run "pip install flask" via cmd line, however it doesn't work. When I attempt to visit the packaging.python.org site, it tells me that I am being blocked and to contact the site admin with my CloudFlare ID (which I have).

I am not sure why exactly I am flagging. Would appreciate any input on how to get in touch with packaging.python.org.

[merwok]

• are you using pop or pip?
• are the connections to packaging.python.org or pypi.python.org

[Spartan149]

Hi there - thanks for the correction, it is indeed "pip".

The connections are to pythonhosted.org however I believe it seems to be working. This is my screenshot of my command line, when I ctrl-click on the "pythonhosted" link, it opens a tab, and auto prompts me to download a whl file, which then downloads. Not sure how this works with the message that is given to me in command line, as it say the hashes are incorrect:

[merwok]

seeing this error message does not make sense, as you are not using a requirements file in the command you’re showing us

do you have a global pip config maybe? (see pip docs to find it)

[Spartan149]

seeing this error message does not make sense, as you are not using a requirements file in the command you’re showing us

do you have a global pip config maybe? (see pip docs to find it)

Thanks for the reply again - I think the pythonhosted.org site is blocking me from visiting due to its Cloudflare settings which is disrupting my capacity to download the python files. When I attempt to visit the link highlighted in red text, it tells me that I have been blocked by the site register and to contact the site owner, quoting my Cloudflare ID number.

Don't suppose you know a way to contact the site admin, given that I cant access the site to submit an email form?

[merwok]

pythonhosted is managed by the pypi admins, on behalf of the PSF.
You should close this ticket and open one there: https://github.com/pypi/support

[Spartan149]

Much obliged, I'll do that, cheers

[webknjaz]

@merwok @Spartan149 that message does not indicate inability to connect to the host. It indicates --require-hashes being in play. This would either be a pip-global setting (likely in the config) or an environment variable PIP_REQUIRE_HASHES. It could also be caused by the presence of PIP_CONSTRAINT (and/or PIP_REQUIREMENT) pointing to a file having at least one --hash.

This is probably an issue for the pip tracker, though.

[pfmoore]

The user is saying that they tried to access the link directly, and got an error saying they had been blocked. That is a connectivity issue.

The hash error may be a separate issue, but the user should ensure that their network access is working first, as it won't be possible to do anything else until that is sorted.

[webknjaz]

@pfmoore oh, I missed that. In one of the comment, they say that the in-browser download works (#815 (comment)) and then that it doesn't (#815 (comment)).
It seems to me that CF treats the client IP as suspicious, but not all the time.

Though, everything is going through Fastly, not CF, which makes me think that there's some weird traffic interception/rerouting in play on the user's site.

[webknjaz]

Thinking more about it, it sounds like there's confusion, coming from @Spartan149 mentioning two different hosts.

I just remembered that packaging.python.org is indeed served by CF. But it's not configured on our side. It's a CNAME pointing to RTD:

$ dig @1.1.1.1 packaging.python.org

; <<>> DiG 9.18.29 <<>> @1.1.1.1 packaging.python.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43573
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;packaging.python.org.		IN	A

;; ANSWER SECTION:
packaging.python.org.	60	IN	CNAME	readthedocs.io.
readthedocs.io.		300	IN	A	104.16.253.120
readthedocs.io.		300	IN	A	104.16.254.120

;; Query time: 39 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Wed Nov 13 20:36:48 CET 2024
;; MSG SIZE  rcvd: 109

So it's Read The Docs that holds the configuration of CloudFlare that ultimately proxies traffic to said docs site and terminates TLS.

And the second one is the PyPI CDN that is terminated through Fastly:

$ dig @1.1.1.1 pythonhosted.org    

; <<>> DiG 9.18.29 <<>> @1.1.1.1 pythonhosted.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58757
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pythonhosted.org.		IN	A

;; ANSWER SECTION:
pythonhosted.org.	86400	IN	A	151.101.64.223
pythonhosted.org.	86400	IN	A	151.101.0.223
pythonhosted.org.	86400	IN	A	151.101.128.223
pythonhosted.org.	86400	IN	A	151.101.192.223

;; Query time: 43 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Wed Nov 13 20:39:08 CET 2024
;; MSG SIZE  rcvd: 109

$ dig @1.1.1.1 files.pythonhosted.org

; <<>> DiG 9.18.29 <<>> @1.1.1.1 files.pythonhosted.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42941
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;files.pythonhosted.org.		IN	A

;; ANSWER SECTION:
files.pythonhosted.org.	86330	IN	CNAME	dualstack.python.map.fastly.net.
dualstack.python.map.fastly.net. 46 IN	A	151.101.64.223
dualstack.python.map.fastly.net. 46 IN	A	151.101.128.223
dualstack.python.map.fastly.net. 46 IN	A	151.101.0.223
dualstack.python.map.fastly.net. 46 IN	A	151.101.192.223

;; Query time: 19 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Wed Nov 13 20:39:11 CET 2024
;; MSG SIZE  rcvd: 160

So based on that, I think that the OP was confusing two entirely different cases and was referring to both interchangeably. And this would suggest that they couldn't access PyPUG because CF wants them to go through their CAPTCHA, while pip install works as expected on the networking level and has hash checking enabled somewhere, which adds to the confusion.