Well, one could also do a openssl-compat package which includes 1.0 versions and symlink. Like every distro on earth has done for several packages ever since the libc5->libc6 thing.
No it’s not pretty and especially with openssl you probably don’t want to depend on an old library, but it’s the “cleaner” solution IMO.
I have actually tried to package GitHub - sailfishos/openssl for 3.4, and partially succeeded (results hidden in my home on OBS), - from these attempts I fully understand why upstream doesn’t want to deal with OpenSSL 1.0 any more.
I fully agree with that, especially considering that libcrypto.so.10 dependency was officially allowed in Jolla Store. But it’s not going to happen, unfortunately.
There’s no problem with packages built in Chum, they automatically get linked with whatever version of openssl is available in those SDKs that they build against.
The problem is only with “one-rpm-fits-all” kind of builds, the ones you’d normally submit to OpenRepos and Jolla Store.
If you provide such a package, app maintainers will rely on that and won’t update their apps, in the end we end up forever using this outdated encryption service.
@slava what does Foil Auth stop from dropping support for OpenSSL 1.0?
Primarily, the absence of OpenSSL 1.1 from older releases of Sailfish OS. Besides, my app doesn’t need anything from OpenSSL 1.1 which wouldn’t exist in OpenSSL 1.0.
Good luck re-writing a dynamic linker My apps pull in 46 functions from libcrypto.
I have to admit that I was actually doing that kind of trick for the libraries which were not allowed in Jolla Store but the thing it that this libcrypto.so.10 dependency WAS officially allowed in Jolla Store. That implied a promise of backward compatibility but turned out to be a joke. That’s what sucks the most. You upgrade the OS and a bunch of apps disappear because some (officially allowed in the previous release!) dependencies can no longer be satisfied. If that happens to an official presumably stable API, guess what can happen to an unofficial API. Is it worth the trouble?
If you need one urgently, you can pick one from Chum. Any rpm built for Sailfish OS 4.0.1 or later is linked with libcrypto.so.1.1 and should be installable on 4.3.
On the flipside: is this actually the first breaking change in SFOS since v0.9 / v1.0? I know the GCC update was a quite a major one, but a non-breaking one…
Maybe there should be wrapper library/api for crypto functions. As it seams that OpenSSL does not provide API stability that long. (like next 8 years) https://www.openssl.org/policies/releasestrat.html
I vaguely remember public statefs APIs getting removed from the platform. But there was a fairly solid justification behind statefs removal, so this probably marks the first time when an officially allowed library gets removed from the OS for no good reason whatsoever.
Ah, yes, statefs. I banged my head into the same reason statefs was dropped. It was released at some time, and dropped a few releases later, because it projected the oddities of the underlying driver layer it was supposed to unify. It was a great idea, but doomed to fail
My apps pull in 46 functions from libcrypto.
Now installable on Sailfish OS 4.3
