I had an excellent couple of weeks. The manage tag siblings and parents dialogs now load and operate quickly, even when the underlying service has hundreds of thousands of pairs. I also cleared a bunch of normal small work.

The release should be as normal tomorrow.

>>1674
>>1675
>>1676
Yeah, I think you are right that this is probably something outside of hydrus, and/or something related to some borked dll somewhere.

Since it specifically cites '_ssl.c:1006' in the error, I'm pretty sure that is a .pyd file (probably _ssl.pyd either in the install dir or your python environment), or _perhaps_ some Windows dll it is calling. Since you can fetch normal https with valid certificates fine, I'm guessing this is happening because of some obscure security policy that is set in your Windows or something that requests (or the ssl pyd somehow) is force-applying despite me saying verify=false, or indeed if there is some init that happens despite the verify=false and that's triggering something else. I'm afraid I am not expert enough in this to talk too cleverly though.

Let me know what you find out! Fingers crossed, this fixes itself anyway when the guy who hosts the PTR refreshes his cert.

P.S. This is a bit in the weeds, but this is as best as I can immediately see where it is working with the 'verify=False' at the coalface: https://github.com/psf/requests/blob/79b74ef704dc0d804937c0d015c5e9c3b02b79bd/src/requests/adapters.py#L111
There's some other stuff in that same file, including line 409, where perhaps there is a route for a non-nothing cert policy to be set despite verify=False. I remembered that 'requests' is build on urllib3, so perhaps that can set a different cert security policy here.

Of course the correct answer, truly, here, is for me to write a proper management system that saves self-signed certs and lets users approve them manually, and then I'd be setting the cert to verify itself or whatever here, instead of False, although maybe that would still fail on an expired.