Log file Viewer

[08:04:54] <x256> Hi there. How do I release a nice pypi name that I never did anything useful with (sorry :/) without risking some bot grabbing it? Any hints?

[09:01:42] <crose> I can't install any package via `$ pip`, probably because of the error “ConnectionResetError(104, 'Connection reset by peer')”. For example `$ python3 -m pip -vvv install --user diceware` fails (https://0x0.st/zmoO.txt).

[09:01:48] <crose> I can't upgrade pip either. `$ python3 -m pip -vvv install --upgrade --user pip` fails because of the same error (https://0x0.st/zmoW.txt).

[09:01:53] <crose> I can't visit https://pypi.org/ from firefox ; the page is blank. However, I can use the site from the Tor browser. Can I configure pip so that it uses Tor when installing some pip packgages?

[09:03:10] <x256> pypi.org is blocked in your company/country?

[09:04:37] <crose> I don't know, my internet provider is OVH. I suspect that my Autonomous system is blacklisted by some sites, because I seem to recall some message mentioning this on a website in the past.

[09:12:40] <x256> That's unfortunate. You could use a proxy/mirror that contacts pypi from an IP that is not blacklistet (maybe tor is an option), or pay for a static IP, and contact pypi.org to unblock your IP (if it's actally blacklisted by pypi, which I'm not sure actually)

[09:23:24] <crose> Yes, I'll try what you suggested. I have this issue since a long time (a year or maybe more). So far, I used to visit pypi.org from the Tor browser. Then I searched for the package I needed, and clicked on the Homepage link. Usually, it lead to GitHub. From there, I cloned the repo locally, and run `$ python3 -m pip install --user --upgrade .`. It worked – although sometimes I had to repeat the process to

[09:23:25] <crose> install a few dependencies first. But now it doesn't seem to work anymore. I think that's because my pip uses `--ignore-installed`, while it didn't before. I could be wrong though.

[09:23:31] <crose> I already searched for documentation to use a proxy/tor in the past, but I never succeeded to make it work. I was wondering whether there was some simple flag or configuration I missed. I'll try to study how pip works when I have more time. Thank you for the help.

[09:57:06] <crose> I managed to make pip work via a proxy: `$ export https_proxy=<ip>:<port> && python3 -m pip install --user diceware`. Now I'm not sure whether the proxy I used will be reliable over time. If it fails, I will try Tor, although I can't find any relevant documentation at the moment, whether on stackoverflow (https://stackoverflow.com/search?q=pip+tor) or on the user guide from pypi.org

[09:57:08] <crose> (https://packaging.python.org/search/?q=tor&check_keywords=yes&area=default).

[10:02:51] <x256> I think it's quite rare that pypi.org has to block IP ranges, so most users do not have this problem. Make sure to use a trustworthy proxy. HTTP Proxys will see your unencrypted traffic and may inject malicious code.

[10:08:30] <crose> Ah yes, you're right. I just chose a proxy from there: https://www.us-proxy.org/ without checking whether it used https. I'll remove the package and re-install from a proxy using https.

[10:09:58] <x256> Does not help. HTTP(S) proxys MUST see unencrypted traffic or they cannot work.

[10:11:29] <x256> Thats why using free proxys from the internet is a bad idea most of the time.

[10:11:50] <crose> I didn't know that; thank you for the information. I guess I'll have to contact pypi.org and ask them if they can help me.

[20:00:08] <njs> x256: uh, no, when you use a proxy to connect to an https site then generally the proxy does not see unencrypted traffic

[20:01:12] <x256> True for socks proxys, but not for HTTP(S) proxys. The proxy needs to know where to direct the traffic, and that information is part of the HTTP(S) request.

[20:01:45] <njs> x256: the proxy sees which site you are connecting to, but that's all

[20:02:30] <njs> x256: the client sends a CONNECT request to the proxy, the proxy sets up a tunnel to the host, and then the client sets up an end-to-end encrypted connection over that tunnel

[20:04:26] <x256> That's the HTTP tunnel protocol, not an HTTP proxy

[20:05:23] <njs> umm, okay, you can call it that if you want?

[20:06:00] <njs> but what I'm describing is how ever http client I've ever seen actually handles TLS + proxies

[20:06:01] <x256> That are the terms used by rfc7230

[20:07:43] <njs> that's both irrelevant and misleading

[20:08:28] <njs> irrelevant because what I'm describing is how http proxies actually work, while you're having some weird arugment about terminology instead

[20:09:21] <njs> and misleading because RFC 7230 does use the word "proxy" when talking about CONNECT mode, for example (from section 5.3.3): "When making a CONNECT request to establish a tunnel through one or more proxies..."

[20:10:39] <njs> anyway, crose was fine, pip used an end-to-end encrypted connection between their host and PyPI, and there was no way for the proxy to see or change the data they downloaded

[20:12:52] <x256> We are both right I think. Curl will use the HTTP proxy protocol (GET http://google.de/ HTTP/1.1 and all headers and contett are visible to the proxy) for http_proxy, and the HTTP tunnel protocol (CONNECT, no content visible) for https_proxy.

[20:19:20] <x256> But yes, proxys for https are fine. I was wrong with that.

[20:53:04] <dstufft> njs: I think requests at one point didn't use CONNECT

[20:53:10] <dstufft> njs: and then YOLO switched at some point

[21:38:05] <dirgeable> hi! echo $GH_AUTH_TOKEN reports the right token but then git clone -q https://github.com/stuffhere/utils.git /tmp/pip-in... asks Username for 'https://github.com any ideas what i could be missing

[21:42:16] <x256> $GH_AUTH_TOKEN does not have any effect on git?

[21:46:53] <dirgeable> thanks! [url "https://thisistotallymytoken:@github.com/"\] insteadOf = https://github.com/

[22:55:10] <njs> dstufft: wut

[23:20:29] <dstufft> njs: can't find the original issue, but https://lukasa.co.uk/2013/07/Python_Requests_And_Proxies/ talks about it

[23:20:39] <dstufft> that blog post was written before CONNECT proxies were a thing in requests

[23:37:23] <njs> that is a nice reminder of how far python http clients have come anyway

[23:37:50] <njs> perhaps soon we will be able to stop using http.client entirely