OpenSSL version used during cx-Freeze build and executable freezing

[HakanSunay]

What version of openssl is cx_Freeze-6.14.7-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl built with?

When I inspect cx_Freeze/bases/lib-dynload/_ssl.cpython-310-x86_64-linux-gnu.so, it mentions openssl-1.1.1t.
I wanted to know if it is possible to use OpenSSL3 instead? If yes, how should we go about it?

One option I could think of is to extend the freezing process of the executable to include a _ssl.cpython-310-x86_64-linux-gnu.so file that was built with OpenSSL3 in lib/ explicitly (this would override the one that is packaged from bases/lib-dynload)?

[marcelotduarte]

We use manylinux to build the wheels, that uses openssl 1.1 (pypa/manylinux@cede922)
To use openssl3, we had to make PR to change this in the manylinux project.

[HakanSunay]

I see that you have created a PR there: pypa/manylinux#1498.

My understanding is that this needs to be merged someday and then picked up by the build system that cx-Freeze uses.
Once that is done, the next release could have the wheels built with OpenSSL-3.0.X.

[HakanSunay]

Would it be possible to hack this by replacing all .so files inside cx_Freeze/bases/lib-dynload with what we have in our own python that is built with OpenSSL-3?

1. Install cx-Freeze.
2. Replace its cx_Freeze/bases/lib-dynload content with files coming from my-openssl3-python/python3.10/lib-dynload.
3. Continue using cx-Freeze as before.

I see that the content of bases/lib-dynload is handled by:

cx_Freeze/setup.py

Line 194 in 97f1432

def _copy_libraries_to_bases(self):

that's why I feel like the above hopefully shouldn't cause any trouble.

[marcelotduarte]

The _ssl*.so made with manylinux does not depend on shared libraries, so it can be copied, as I do.
If your system use a _ssl that depends on shared libraries, you can have trouble with the missing dependency. In the build machine it can work, in similar systems too.

[HakanSunay]

Yes, our _ssl*.so depends on shared libraries like libssl.so.3 and libcrypto.so.3:

$ ldd _ssl.cpython-311-x86_64-linux-gnu.so
        linux-vdso.so.1 (0x00007ffc429b2000)
	libssl.so.3 => <redacted>/libssl.so.3 (0x00007fbd51ab8000)
	libcrypto.so.3 => <redacted>/libcrypto.so.3 (0x00007fbd51508000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbd512e9000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbd50ef8000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbd50cf4000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fbd51972000)

Yet, we have them packaged as part of the freezing process so they are readily available.
Also, we have not observed any regression in our testing yet.

[marcelotduarte]

Release 6.15.9 is out!

ssl OpenSSL 3.0.10 1 Aug 2023