[Wiki] Missing libcrypto.so.10 / libssl.so.10 breaks several apps on SailfishOS ≥ 4.3.0

General
#21

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 https://github.com/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.

3 Likes
#22

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.

2 Likes
#23

So:

  • repackage contents of openssl 1.0 from SFOS3.4 into openssl-compat RPM
  • add Provides:/Conflicts: to original openssl
  • publish on Chum
  • publish on Openrepos
  • have community maintain it on Chum

Would that be a smart thing to do?

2 Likes
#24

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.

#25

I’m aware of that, I’m thinking more or making packages from Store work again that will break now and not be updated.

1 Like
#26

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?

2 Likes
#28

If you would just have read the link I gave you, this question and the other misunderstandings could have been prevented.

#29

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.

2 Likes
#30

There is no universal solution… Unless there’s a way to make a binary use either libcrypto.so.1.1 or libcrypto.so.10, whichever is available.

#31

I think libcrypto.so.10 or libcrypto.so.1.1 can be loaded at runtime with dlopen(). Without linking.

2 Likes
#32

Good luck re-writing a dynamic linker :slight_smile: 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?

4 Likes
#33

FWIW, I’ve fixed harbour-foilauth rpm in OpenRepos to link OpenSSL 1.0 statically. Enjoy a 1.5 MB executable :slight_smile: Now installable on Sailfish OS 4.3

6 Likes
#34

A word, or two, would’ve helped.
Thanks for the info.

#35

Could you PLEASE do the same for FoilNotes?
Just lost an access to one of bank accounts…

#36

Will do, of course!

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.

1 Like
#37

And this api change will happen again on OpenSSL 3.0 switch. :frowning_face:

#38

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…

#39

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

#40

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.

2 Likes
#41

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 :frowning: