tests: fix SSL test on python 3.13 by being more lenient about VERIFY_X509_STRICT

[eli-schwartz]

In python 3.13, this flag was added to the default created ctx. This seems reasonable for production validation, but the unittest code generates a certificate that fails this. Inside test code, it seems fine to relax the constraints again. Our goal is to test the server itself, anyway, not the ssl module.

See also: python/cpython#107361

[eli-schwartz]

Testing 3.13 compatibility for Gentoo with the release candidate. This was the only test that failed.

I I took a hasty stab at trying to update the custom certgen module to generate a stricter certificate, but ran into weird errors that indicate I don't understand the nuances of the SSL certificate internal specification, which is... fair, because I don't. At that point I decided to simply not bother since it is only ever used by the testsuite anyway and there's no public API to worry about.

[kovidgoyal]

The big breakage will come when nogil is made the default/compulsory.
I don't know what it is about the Python developers, they just love
creating busy work for their ecosystem. They seem utterly unable to
either design things right to start with or failing that evolve their
designs in backward compatible ways.

As for this issue, yeah your fix is fine. Not going to wrestle with
OpenSSLs certification machinery for this test.

[eli-schwartz]

I haven't been following nogil super close, but my impression was they intended to have a veeeeeeeeeeeeery long rollout so they can let people catch issues, and e.g. importing an extension that doesn't declare support will immediately cause the entire interpreter to be marked as requiring the GIL.

It's even in the PEP as:

The Steering Council accepts PEP 703, but with clear provisio: that the rollout be gradual and break as little as possible, and that we can roll back any changes that turn out to be too disruptive – which includes potentially rolling back all of PEP 703 entirely if necessary (however unlikely or undesirable we expect that to be).

[eli-schwartz]

I'm more worried about the JIT which doesn't seem to be entirely well-tested and is now completely masked in Gentoo after too many teething issues to even be worth experimental "for fun" testing. Someone even suggested adding a USE=bonkers flag that would be required in order to also set USE=jit, and I'm not too sure it was a joke.

And the JIT is actually supposed to be perfectly equal and backwards compatible...

[kovidgoyal]

On Wed, Aug 14, 2024 at 06:40:57PM -0700, Eli Schwartz wrote: I haven't been following nogil super close, but my impression was they intended to have a veeeeeeeeeeeeery long rollout so they can let people catch issues, and e.g. importing an extension that doesn't declare support will immediately cause the entire interpreter to be marked as requiring the GIL.

Yeah all that brilliant plan means is that in a year or two the ecosystem will be divided between C extensions that require nogil, C extensions that require GIL and C extensions that work with either. And using multiple C extensions of different provenance in the same Python process will become increasingly difficult. One can hope that category (1) above never becomes too large, but personally, I doubt it. One can further hope that before rolling out nogil the developers would have spent some time creating tooling to help migrate/check C extensions, but going by past performance I would be shocked if they did. No doubt in 5ish years third parties will create reasonably robust tooling for it.

[eli-schwartz]

They added a module slot entry so that you can specify whether you are category 2 or category 3, as far as I know they don't intend to support category 1 at all or at least if you do somehow require nogil the cpython project considers you to be on your own.

Fingers crossed that it will stay that way. ;)

[kovidgoyal]

On Wed, Aug 14, 2024 at 06:46:00PM -0700, Eli Schwartz wrote: I'm more worried about the JIT which doesn't seem to be entirely well-tested and is now completely masked in Gentoo after too many teething issues to even be worth experimental "for fun" testing. Someone even suggested adding a USE=bonkers flag that would be required in order to also set USE=jit, and I'm not too sure it was a joke.

Isn't the JIT off by default needing some compile time flag to turn it on? At least that was the case when last I looked at it. And unlike nogil, which will actually regress performance for 99% of python code, JIT at least theoretically, has the potential to be actually useful, so I am inclined to cut it some slack.

[eli-schwartz]

Well yes and no. Both JIT and nogil are experimental features that need to be manually enabled at compile time.

But nogil is the one that people expect to potentially break the world, so it's the one that everyone is focused on being cautious about. :)

The readiness for being made the default is explicitly called out in the jit PEP: the reason it's not ready yet is because "it isn't a clear win and we need to decide how much additional speed vs increased memory use is the criteria for making it the default".

If it was just faster today, it sounds like they'd just... toggle it on.

[kovidgoyal]

Ah thanks, good to know. I dont envy the life of distribution
maintainers, this sounds like another python 2->3 except this time they
are too chicken to actually bump the major version despite making large
breaking changes. Maybe we will get to enjoy Python 4 when these two
are declared "stable" in the minds of the python developers.

But let me not be too negative, apart from the 2->3 transition
developing with Python has been generally pleasant. And I do admire
their courage in making such large changes in such a large ecosytem.