Jakub Kulík

That's true, currently it fails with a pretty ugly: ``` cryptography.exceptions.InternalError: Unknown OpenSSL error. This error is commonly encountered when another library is not cleaning up the OpenSSL error stack....

Maybe mirror the OpenSSL library itself - that is, if legacy provider is enabled globally (via the OpenSSL configuration file), then don't ask and just enable it (in which case...

I created WIP PR #7391 for this (with the simplest changes I came up with that allow this).

I've just hit this on Solaris (SPARC) as well - any update on this (or workaround)? I tried replacing the `ip = (struct ip *) (p + offset);` in `accept_ip`...

I found the issue and managed to fix it with PR #2508.

So I tried looking into this again with the latest OpenSSL 3.0.5, and while the call stack changed a little bit, the same issue is still there. ```gdb > ::stack...

I have an update regarding this (and big thanks for helping goes to @mattcaswell (in the OpenSSL issue)). The problem is that the `NmapOps::~NmapOps()` called from exit handler (that eventually...

Thanks for the update, I will try it the first thing tomorrow morning. I am just wondering; since the OpenSSL exit handler is AFAICT always called before the Nmap one...

So I just tested it with the latest master ([1f50e82](https://github.com/nmap/nmap/commit/1f50e82dd2bd89b6d25d0421d5022e1a5983a7ef)) and it doesn't segfault anymore (with context never being cleared).

I just had a similar problem when trying to test pytest-django on Solaris, and the problem was that `pytest_django_test` isn't being delivered, meaning that if you are running the test...