Nightly/R1B5 - Ported apps -- to be recompiled -- due to OpenSSL 3.x introduction

Software Ports
1

Ahoy !

I opened this new thread to mention apps where reconfig and addition needed to recompile to work againg together
with upgraded TLS/SSL version.

As OpenSSL v1.1 lifecycle has ended - on Haiku - it was resolved by intruducing a backward compatible, but newer openssl 3.x version.

It was followed on many packages but
there are more that had not scoped closely by the OS itself
and / or
especially all other ported or 3rd party applications running on Haiku (32 and 64 bit either).

I thought I open this thread and someone who has a Github account and (would) use that application can report there as well - ( just as ) the maintainer(s) may not follow the forum posts.

Actually I accept developers decision to use Github for reporting issues of such apps
but , at the same time , I still do not want create an account … just for that reporting.

I am not a developer, so I do not need and want to have that account so far.

These issues can be experienced , at this moment .

on Nightly (master branch)


and / or

on the shaping new beta (r1beta5 branch)


Thanks in advance for your acceptance and understanding –

… especially those ones who are going to / would immediately propose the opening an issue about it on Github.
For them I kindly ask to read again the opening post. (THIS ONE :)) )

1 Like
2

#01 Otter browser

01)) Otter_browser

Warning : SSL_support_is_not_available_or_incomplete

nightly build , hrev57980

arch → x86_64

01__Otter_browser__SSL_support_is_not_available_or_incomplete__hrev57980__x86_64

02)) Otter_browser

99 network failure –ADVANCED → TLS_not_initialised, SSL_librarary_is_not_available

nightly build , hrev57980

arch → x86_64

02_edited__Otter_browser__TLS_not_initialised__SSL_librarary_is_not_available__hrev57980__x86_64
02_edited__Otter_browser__TLS_not_initialised__SSL_librarary_is_not_available__hrev57980__x86_641920Ă—1080 259 KB

1 Like
3

I think that we kept this version of Otter because it is the last one not using QtWebengine. Let’s hope migrating to OpenSSL 3 won’t force us the hand.

4

As far as I know,the same version of Otter Browser can be compiled with either QtWebKit or QtWebEngine by switching some configure flags.
Also,this is the latest version of Otter Browser that I can find on Sourceforge,and FreeBSD has the same in their repo (but with WebEngine,unfortunately),so it should support OpenSSL 3 just fine.

5

The changeover to OpenSSl 3 is going to be very time consuming as even just a rebuild of a package will have some interesting things. For example I rebuilt Falkon with OpenSSl 3 and it works great, however Adblock is not working at all.

I also did a built of Otter with WebEngine enable with OpenSSl 3 which so far works fine however, I do have the following:

screenshot1
screenshot11280Ă—1024 50.1 KB

Going thru the source you’ll find it here:

screenshot2
screenshot21280Ă—1024 119 KB

6

Interesting - I got the same warning in Hungarian, however my Otter package had not recompiled, just have
→ package opnssl - OpenSSL v1.1 1.1.1w-2 x86_64
and
→ package opnssl3 - OpenSSL v3.0 3.0.14-1 x86_64
both installed in my 64 bit nightly Haiku.

When I updated nightly I had not checked the old version uninstalled or not, I’ve just seen the patch added the new version.

Strange, then Otter should work as Falkon, actually, as Falkon still works as expected.
Otter seems uses a different way to find a supporting library than Falkon.

7

So OpenSSL was updated because “number must go up”, and nobody bothered to check whether or not applications that use OpenSSL are compatible? This is why users don’t like package managers.

8

This sentences proves that you had not read carefully my opening post.
Otherwise
→ you would not state the reason behind is … as you did : “number must go up”

old version - v1.1.1 - lifecycle has ended … on 11 Sep 2023

This phrase means , the providers (developers ) of that SW / library

→ do not release new fixes to that version
→ more importantly do not give further support after a specific date.

→ also was bothered to remain compatible , as there was more recent version … but they decided to select an LTS version , aka LONG TERM SUPPORTED one, instead of more recent but simple release.

OpenSSL v3.0.14
released on 07 Sep 2021
its lifecycle ends on 07 Sep 2026

This version still enables deprecated functions, however the software which would use SSL/TLS should recompile.
Also , on nightly - v1.1.1 still available … at least for updated installs.
For fresh install - I do not know actually.

I like the package management systems, but really it has pros nad cons just as anything can have if we judge them from our perspective.

1 Like
9

No, Haiku now uses OpenSSL3 because OpenSSl1 is deprecated.
(This situation would have appeared even if Haiku had no package manager, just that you as a user would have even less recourse…)

You are free to use applications that use OpenSSL1, it is still available and can be installed.

The only problem appears when an application links to both openssl3 and openssl1, for example when an application is linked against openssl1 and one of it’s dependencies is linked against openssl3.

To get out of that you can for example use an older version of the dependency that does not link against openssl3.

There is no need to force everything into openssl3 just because. In some instances it will make sense to simply keep openssl1.

On my personal install i don’t want openssl1, but that is just because I don’t like having duplicated packages, a personal preference if anything.

1 Like
10

If that’s the case, why is there a need to wait for applications to be recompiled? Anything that worked should still work without being recompiled and this update should be more or less invisible.

11

Applications whose dependencies use openssl1, but use openssl3 themselves are problematic, as is the inverse. Those are the ones that may need to be recompiled to avoid crashes.

Anyway, this thread is not any official thing from haikuports but just a users opinion. If you encounter an application that crashes as a result from this you can open a ticket and we can fix it, otherwise there is nothing that needs to be done.

Regards

2 Likes
12

Which means they worked fine before and now they don’t. Why was this breakage allowed to happen?

13

Openssl version 3 has changed their API to make it harder to accidentally misuse the library, and has removed openssl1 compatibility.

The applications (with their deps) that worked fine continue to do so… You only get a problem if you effectively only update “half” of your application to openssl3. And even if you have libraries that switched version you can just keep the old versions with the older application and keep using it.

Don’t really see the problem there?

14

I don’t care about the OpenSSL project and why they made the changes that they made. I’m concerned about breakage. Do we or do we not need to recompile applications that worked fine up until this point? If they need to be recompiled, that is a problem.

15

Dear @x68k ,

This thread is not about your concerns. Please stop your writing to here.

This thread to people with reasoning and not about
“stop development as you always break my fav toys, and make me frustrated”.

This is for adult people, who understand what it is about - based on my opening post -

You are very off topic here, and your posts do not add helpful or useful surplus.to this thread.

Kind regards,

16

@x68k may speak. As I understand this OpenSSL was updated for r1beta5. It makes sense that if you need to break compat and force apps to recompile this is the time to do it.

2 Likes
17

For me the status is the same as with the transition with beta4, atm still running beta4, so can’t check builds for apps broken atm due to the transistion to openssl3 (I know for one nexcloud_client is one of them being broken atm).
So once R1B5 is out we (at haikuports) can begin to look into what is broken or not I guess.

18

As I already said, No.

If you start the same Image that worked before (i.e the same application and set of dependencies) then that will continue to work, as we have not broken Binary compatibility.

19

The situation, is, as usual, more complicated.

OpenSSL is used in many places, a lot of things depend on it both directly (by linking to it) and indirectly (by linking to things that depend on it).

We introduced OpenSSL 3, but we also kept OpenSSL 1.1.1. The versions are not ABI compatible, and the libraries have different names, so, in theory, old applications could continue to use OpenSSL 1.1.1 and newly recompiled applications and libraries will use OpenSSL 3. This should allow a smooth transition.

The problem is, when one library is updated to use OpenSSL 3, but applications using that library are also using OpenSSL 1.1.1 (directly, or by using another library that uses OpenSSL 1.1.1).

You may have noticed that, while we work on this, the updates for the beta 4 installation have been disabled. So, it is not possible to accidentally install any of these broken version in beta releases of Haiku. Ideally, we would have a “frozen” repository with no updates at all for beta 4 during this transition period, or we would have stable/experimental channels for haikuports packages. But this is not the case. So, beta 4 get no update, and nightlies get some breakage while we migrate everything to OpenSSL3. If you are a normal user who uses beta releases and not nightlies, as we recommend to do to normal users because nightlies occasionally get broken, you see none of these problems.

If you use a nightly build, well, you have been warned that this is a nightly build, and it sometimes break while we work on such things. We have to do this testing work somewhere, and the nightly builds is the place to do it.

This situation will be resolved before beta 5 by having recompiled all libraries at haikuports to update them to OpenSSL3. But it will still be possible to install OpenSSL 1.1.1 if you have some old application (from outside haikuports) that depends on it. If your application relies on a mix of haikuports libraries and self-compiled things, you may have a bit more problems, but that is the case with any other package manager system, and there is not much more we can do about it.

OpenSSL is working on removing a lot of technical debt, they made internal APIs much cleaner and will continue to do so in future releases. This comes with some breakages now, in order to make future updates easier. They can’t keep maintaining full compatibility with the old APIs, which are broken and dangerous to use. It’s not just a “version numbers must go up” thing.

6 Likes
20

Will this be done by a automatic script? Having a full rebuild of all of them is a major job. :slight_smile: