>>1671>>1672Thank you, this is an interesting report. Since most hydrus repositories are run with a self-signed http cert (since they are hosted off of local networks and such), hydrus is set to not actually verify hydrus traffic. i.e. In the 'requests' Session, I explicitly set 'verify=False'.
https://github.com/hydrusnetwork/hydrus/blob/master/hydrus/client/networking/ClientNetworkingSessions.py#L228It is normal to have to add an exception if you look at a repo's landing page html with your browser. The PTR has usually been an exception since it had a real cert.
So this is odd. Even if the PTR Let's Encrypt cert has expired, hydrus itself shouldn't care since I tell it to use it anyway. You are the only report of this, and when I extract a fresh extract, I can get it to talk to the PTR with no problems, and since you get it with source too, that suggests there is something else in your environment going on here.
This part, 'unable to get local issuer certificate', I wonder what that really means. I think that 'requests' might in some situations ask your OS for some root cert stuff, so is there any chance you have an unusual setup for Windows itself? I assume you can download from normal https sites fine with hydrus, and it is just the PTR that has trouble? So I wonder if somehow requests is going 'hey OS, please give me your root cert, I want to see if this hydrus cert is ok', and the OS is going 'uh, that hydrus cert violates my policy, I refuse to give you my root cert', or
something like that, so OS policy is overriding hydrus policy.
The requests root cert is under 'install_dir/certifi' folder I think. It is just this:
https://pypi.org/project/certifi/ I wouldn't have thought it would need to poke your OS given it has that, but perhaps there's something else going on. Do you have that 'cacert.pem' file in that folder, or is it possible some anti-virus or something has quarantined it? I would have thought that setting 'verify = False' to the requests Session would skip all this shit, but perhaps not.