About Libressl, it has a small team, few contributions from big projects, and there is also complacency and laziness from big projects to contribute, after all Openssl receives millions in money from corporations and the community has become comfortable with this, Libressl devs are willing to collaborate, as long as there is a conversation.
I opened a ticket a while ago, there is a lot of discussion about this and links about Alpine Linux, talking about it:
There’s also WolfSSL, which seems ok
One-to-one Openssl alternative is Libressl, the curve is small, as it has similarities, any different software, it is hard work, a lot of rewriting.
No, not at all. LibreSSL is a fork of OpenSSL 0.9.8. Since then, there has been OpenSSL 1.0, 1.1, and 3.0, each bringing many new APIs and removing old ones.
So, if you have an application written for OpenSSL 0.9.8, then yes, you can switch to LibreSSL. But for any code written in the last 5 years, there is no way this will work. The curve is not small anymore.
Something else in the dependency chain for Otter is still using OpenSSL 1 and must be rebuilt.
It seems it’s qt5 base libraries dynamically loading the unversioned .so and not finding it:
At this point, yes, I mean compared to other ssl solutions, Libressl and Openssl the curve is smaller, compared to any other solution.
What about Web browser ?
Would be enough a new webkit-gtk package that recompiled for OpenSSL v3 ?
There was a new update package released recently …
> find /boot/system -name webkit_gtk*.hpkg
/boot/system/packages/administrative/state_2024-08-14_23:13:08/webkit_gtk-2.40.0-1-x86_64.hpkg
/boot/system/packages/administrative/state_2024-08-14_23:13:08/webkit_gtk_demo-2.40.0-1-x86_64.hpkg
/boot/system/packages/administrative/state_2024-08-22_19:00:40/webkit_gtk-2.40.0-2-x86_64.hpkg
/boot/system/packages/administrative/state_2024-08-22_19:00:40/webkit_gtk_demo-2.40.0-2-x86_64.hpkg
/boot/system/packages/webkit_gtk-2.40.0-3-x86_64.hpkg
/boot/system/packages/webkit_gtk_demo-2.40.0-3-x86_64.hpkg
~> ls -l /boot/system/packages/webkit_gtk*
-rw-r--r-- 1 user root 58109 aug. 23 20:20 /boot/system/packages/webkit_gtk_demo-2.40.0-3-x86_64.hpkg
-rw-r--r-- 1 user root 37301396 aug. 23 20:20 /boot/system/packages/webkit_gtk-2.40.0-3-x86_64.hpkg
~>
I am working on rebuilding all packages which depend on old openssl versions. I did the “easy” ones first, but there are several that don’t build for various reasons (dead downloadlinks, not compatible with openssl 3, not compatible with some other package updaees or changes in Haiku, …).
So it will take some time before I get them all done.
I’m on the same pace as @PulkoMandy tackled a few already and then the ones I use mostly on a daily base here, now looking into the other ones (at this moment scummvm - probably need to send a patch upstream for this).
GTK has been kinda broken here, I can run some checks later. WIP 
For the record, it’s a team efford, not a 2 mans job. 
As far as the list was published, I’m done, the ones still there are too much for my skills or not even supporting openssl3.
Still some recipes not mentioning version string for the devel packages for openssl3, but I guess we should tackle them when it comes to it.
This is again a problem of bad ELF design with its “junk yard” symbol resolution. PE executables have no such problem because it use 2 level symbol resolution (library name → symbol name). For example multiple versions of C++ runtime libraries can peacefully exist in the same process.
It is no theory possible to introduce 2 level symbol resolution in ELF by making symbol versioning mandatory and using default version if not explicitly defined. When symbol versioning is enabled in importing image, it also declare imported library name so it become possible to implement 2 level symbol resolution.
Major commercial OSes such as Windows and MacOS use 2 level symbol resolution. Older BeOS PPC and PE x86 versions also used it.
We have discussed this a dozen time, and I will repeat the same thing: it is not a problem with the ELF format itself, but with the way it is used and of the tools (linkers and compilers).
You could do globally shared variables with Pe files if you wanted to. And you could do hidden variables in an ELF file easily.
Anyway, I’m not sure what to do of your comment. Are you advocating for aiku to switch to PE file format for executables? I’m not sure that’s a good idea because the tooling for generating PE executables from gcc and ld seems pretty bad (they used to have good support, but they removed it for some architectures).
Or are you suggesting that openssl should use less globally shared state? Certainly a good idea, sharing things this way is just bad design, but there is not much we can do about it.
If tools allows to use format in wrong way and it is a default option, it is a problem of format too.
I am advocating to at least change linker default options so VERNEED tables will be unconditionally generated and library name declared there will be used for 2 level symbol lookup. Bump Haiku ABI version and refuse to load ELF executabes with new ABI version without VERNEED table.
WolfSSL has good reputation. Otherwise a big alternative is GnuTLS.
though far from all applications support or can be compiled with anything but OpenSSL. Likely not a project possible to undertake at this time. Perhaps Haiku internals could be adapted to use something better?