avoid pyOpenSSL 23.1.0

[alexzorin]

Our NO_PIN test fails due to pyca/pyopenssl#1199.

This PR might strictly not be necessary once a new release of PyOpenSSL is available? I suppose it depends whether they yank the release.

[bmw]

Thanks Alex! I think us merging this is fine. We can always change or remove it in the future if we want.

[alex]

Hey, I don't think we changed the behavior of get_short_name in the last 10 years :-) Do you have better insight into why reverting to an older pyOpenSSL solves this?

[alexzorin]

I took a closer look:

The regression is in OpenSSL 3.1.0. cryptography>=40.0.0 wheels are the first to be compiled using OpenSSL 3.1.0, and pyOpenSSL==23.1.0 was the first version to be compatible with cryptography>40,<41.

If I understand what's happening, once there is a new release of OpenSSL and cryptography wheel using that release, we can get rid of the constraint.

[alex]

Great, we're looking at a pyOpenSSL fix/workaround and doing a quick release for that.

…

On Mon, Mar 27, 2023 at 6:07 PM alexzorin ***@***.***> wrote: I took a closer look: The regression <openssl/openssl#20555> is in OpenSSL 3.1.0. cryptography>=40.0.0 wheels are the first to be compiled using OpenSSL 3.1.0, and pyOpenSSL==23.1.0 was the first version to be compatible with cryptography>40,<41. If I understand what's happening, once there is a new release of OpenSSL and cryptography wheel using that release, we can get rid of the constraint. — Reply to this email directly, view it on GitHub <#9631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBGQDYIO6TSOSHVRAJ3W6IFQ3ANCNFSM6AAAAAAWISHA2I> . You are receiving this because you commented.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[alex]

We've now released a new pyopenssl, and confirmed that it works. Because you just did a != check, I don't think you have any additional requirements.