There isn’t a script at the moment, so, no, it’s the manual rebuild we are doing. Unless someone wants to write a script for it, but I’m not sure how easy this is. I think you need access to the already built packages to check which ones use the old OpenSSL? Or can it be done from the recipes only?
And also, even if the script can find what needs to be rebuilt, it seems several packages are also broken for other reasons and will need a bit of manual work anyways.
Thought so, I’m guessing we have to go along the ride to see what “needs” to be fixed on runtime, lots of packages have a requirement for either lib:libopenssl or lib:libcrypto, but I also guess that not all “need” a rebuild, hard to track for me at the moment still running R1B4.
Was covered in detail by @PulkoMandy, but if I understand correctly the key point is that for end users there is no breakage: They dont need to care. The package manager takes care of this problem.
To expand in my comment about this, when we jumped into this while trying to guess what was up with Beam - it is my experience that
libssl.so.1.1-lssl to something, presumably an existing libssl.so.3OpenSSL documentation does suggest that this might work, the way I read it, but of course I’ll be looking at my code to square it up with 3.0.
You can install the “openssl” package if you want to run old binaries, side by side with the new “openssl3” package. As long as the applications that use openssl 1.1.1 don’t also link in openssl 3, you are fine.
Usually we try to do these changes a bit more quietly, but in this case, due to the usage of OpenSSL in Haiku itself and pretty much everywhere else, it takes quite a bit of time, and it needs to be done after the beta release branching. And it is also quite difficult to do completely smoothly. So this situation lasts a bit more thna usual for these things.
I wonder if this exposes a limitation of HaikuDepot. pkgman shows that openssl package, and openssl_devel, but HaikuDepot shows only openssl3 and openssl3_devell.
This is I believe the heart of @x68k’s complaint. It’s not inherent to the design of package managers that this can’t work, it is the fault of our implementation of the package manager that is unable to cope with this situation. Gentoo Linux deviates from other package managers and implements a more flexible package management system that allows multiple versions of packages to be installed and used simultaneously by different apps.
Let’s say for example that you have an old package, say from beta1 that you’d like to use. Will you be able to install it and have it work on beta5 or will it error out saying package dependency not found or symbol not found? If so, isn’t that a problem?
Perhaps I do not fully grasp what the problem is but I understand where @x68k is coming from. He wants old packages to work and we don’t want to redesign the package management system that is necessary to make that happen.
Short of redesigning the package management system we’re not able to do this in the beta5 timeline so here we are, we’ll have to do the best we can with what we have already built.
It won‘t work because old packages aren‘t hosted indefinitely at haikuports. But that is not a design problem or decision of the package management.
Haiku packages can be co-installed to other locations fine, and ran from there.
It isn’t. You can have both installed at once, and have the OpenSSL 1 version from beta4 installed on beta5. That all works. The problem is that you cannot have OpenSSL 1 and 3 loaded in the same application without running into issues, which isn’t the package manager’s fault at all.
That makes sense, sure. So then why do apps need to be recompiled to run on r1beta5, shouldn’t they run on the old OpenSSL version and only optionally be recompiled to upgrade the OpenSSL version used? Is that the case?
Haiku’s own Network API now compiles against OpenSSL 3, so anything that links against it which also used OpenSSL directly will need to be recompiled. The same goes for Qt and a lot of other packages in HaikuPorts.
Thst makes sense, the Network API was updated to incompatible OpenSSL version. The idea that you may maintain your own OpenSSL is specious because a bunch of apps and Qt rely on the Network API and its OpenSSL version provided by the Haiku package. To prevent breakage from happening in the future we’d have to maintain two network API packages, we’d have to split the network API out of the main haiku package to maintain separate versions. I understand we don’t want to do this right now because it’s too much work.
No, Qt does not rely on Haiku’s network APIs, that’s not the issue. Something else in the dependency chain for Otter is still using OpenSSL 1 and must be rebuilt.
The API is not changed, and is perfectly compatible. The problems are deep inside OpenSSL ABI. This wouldn’t happen if OpenSSL did proper symbol versioning and/or did not rely so much on global context for a lot of things, instead of passing it explicitly as function parameters.
OpenSSL 3 is fixing a lot of these problems, and so hopefully, in future versions this won’t be such a problem.
For Haiku apps this change is transparent if they didn’t use OpenSSL APIs directly and instead used BSecureSocket, for example. For apps that are ported from Linux and use a thousand dependencies, all the dependencies have to be rebuilt. As far as I know, all Linux distributions manage this by just rebuilding everything.
I remember when the heart-bleed bug was publicized and OpenSSL took a bunch of flack for it, at least by the OpenBSD devs for being poorly maintained. Hopefully OpenSSL 3 fixes some of their poor design decisions. Being such a prominent and important security product used by so many (including Haiku) made it a bigger deal.
I was only trying to understand what the deal was with OpenSSL and now I do, so thank you.
I’m not sure that Gentoo-like package management would have made a difference here, seems like the issue is an OpenSSL ABI break and there’s no avoiding it.
Was there a reason to use OpenSSL 3 instead of Libre or Boring?
Yes, I can confirm. Otter browser shipped first with QtWebEngine, but now QtWebKit also enlisted as an engine on the wikipage.
Official repository – https://github.com/OtterBrowser/otter-browser
Yepp , SourceForge also used, basically for binaries under Linux, *BSD, Windows and mac OS.
OK, so the browser version itself the latest available from 2022, so no newer version may help to detect better the installed OpenSSL library -
As in case both installed, even if it is recompiled for v3.0 usage we get
the same warning.
I mean on nightly I have a not recompiled version of Otter with both SSL library available, meanwhile dasouth recompiled Otter for SSL v3.x and got the same warning like me.
Is it possible to open an issue should be opened upstream ?
Or there is some act on our side that can help ? Like some debugging ?
LibreSSL Removed support for obscure platforms, like Haiku ; )
and boringssl is effectively useless, It‘s good for chomium and nothing else.
And also, the problems with OpenSSL were not unfixable, and OpenSSL 3 fixes some of them. So the “there is a problem with this project, let’s fork it” approach isn’t great, when the original project is actually doing reasonably well now.
Let me ask the questio nthe other way around: what would we gain by switching to LibreSSL or BoringSSL? BoringSSL does not seem to have any releases since 2022. It’s a Google “just get the latest git revision project”. They also use modern compilers (no way to build it on gcc2), so we would still need to maintain OpenSSL anyways.
I have not followed the evolution of LibreSSL too closely, but I would say it looks like the OpenBSD developers cornered themselves with it, and everyone else decided to work on improving OpenSSL instead. I may be wrong.
The issue was missing talking to devs and presenting code for Haiku on Libressl’s github. In the past, there was a code presentation for Haiku on the email list, which is not the best channel, as github is used.