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.
2 Likes
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 
That time around it wasn’t just about removing a library - statefs was too deeply integrated into the OS. Dropping it (for apparently good reasons) and still providing emulation of the public API was a clear no-go. That breakage was at least understandable.
I would consider the facts that openssl is a security critical library, from 2015, and it’s maintenance ended almost 2 years to be very good reasons…
2 Likes
First of all, “unmaintained” doesn’t necessarily mean “broken”. My apps use MD5, SHA, AES and RSA - chances of those being critically broken in openssl 1.0 are extremely small, almost non-existent. My own code has a greater chance of having a critical vulnerability.
Second of all, most 3rd party devs don’t care about maintaining compatibility with older releases of Sailfish OS. Just introducing openssl 1.1 and making it a default would cause a gradual migration to openssl 1.1 without a major drama. Leaving openssl 1.0 around (as a separate package installable on demand) wouldn’t make a slightest difference on that front.
Where removal of openssl 1.0 does make a major difference is a) unmaintained but still functional apps and b) maintained but for whatever reason requiring backward compatibility with older releases of the OS. The a) group would just get silently uninstalled with no hope of bringing them back and b) updated to link openssl 1.0 statically. Is that an improvement worth the trouble?
2 Likes
Doesn’t seem too difficult with the Qt libraries…
@piggz does it in advanced camera, it seems like a simple QLibrary.load()
2 Likes
sshhhhhh, we dont talk about methods to bypass harbour restrictions here 
6 Likes
Yeah, I know. I’ve been doing this kind of stuff myself when I had no choice, but I try to avoid it. If there’s an allowed public API which does what I need, I prefer to use that.
1 Like
@sunkan @pherjung Please try these statically linked builds: build (#1756009877) · Jobs · Heng Ye / Sailtrix · GitLab
1 Like
Hello
I am also trying to manually install the rpm, but I am asked to enter the insertion code (corresponding to the unlock code by phone) it does not work. can you tell me what code to use? Thanks
== AUTHENTICATING FOR org.freedesktop.packagekit.package-install ===
È richiesto autenticarsi per installare software
Multiple identities can be used for authentication:
- sailfish-code
- sailfish-fingerprint
Choose identity to authenticate as (1-2):
I used user nemo, but I have pkcon as an alias with an extra sudo pkcon privilege.
You should run it as root (type devel-su first, it will probably ask for a password).
just look here: curl | OpenRepos.net — Community Repository System
https://openrepos.net/sites/default/files/packages/7598/openssl-libs10-1.0.2o-2.armv7hl.rpm contains libcrypto.so.10 and can be installed independently of openssl1.1.1l packages from jolla SFOS4.3 (even on a Jolla1) which are availabe here, too.
the solution as a user (e.g. jolla1) is to install both libraries: [4.3.0.12][WIKI] Missing libcrypto.so.10 breaks several apps - #51 by lpr
as a developer you can simply link against openssl1.1.1l which runs on all devices this way (only avoid sailfish-silica/sailjail/androidmedia stuff later than SFOS3.4 what would break compatibility)
You need to be root (devel-su) to use rpm, OR use a terminal which can connect to the SFOS UI (which will then prompt for the code). Things like remote ssh sessions, or screen will cause this output.
There is also the possibility to not use openssl at all, but instead use mbedtls.
Probably not feasible for a lot of existing apps, but if you need SSL/TLS and are willing to ship your own lib for it, going for mbedtls could be an alternative to static linking.
I have a (very customized) build of it in chum for privoxy in case anyone wants to try.
2 Likes
After thinking about it a bit more, I ended up loading libcrypto.so dynamically. That seems to work for me and if it doesn’t break again any time soon then this approach may be even better than static linkage.
5 Likes
Hi,
I uploaded new builds for qca-qt5 and MeePasswords for SailfishOS 4.3 to OpenRepos and to the Mer OBS:
OpenRepos
- qca-qt5 | OpenRepos.net — Community Repository System
- MeePasswords | OpenRepos.net — Community Repository System
Mer OBS:
Unfortunately, the Forum doesn’t allow me to post more links as my account is new. So, I cannot put the Mer OBS links in here. But I mention the links in a comment to the MeePasswords package on OpenRepos.
Unfortunately, I don’t have access to a SailfishOS device, right now, so I could not test anything.
I hope these packages are useful for some.
Cheers,
Ruediger
3 Likes
PS: Here are also the links to the OBS repositories:
https://repo.sailfishos.org/obs/home:/wonko:/sfos/
https://build.merproject.org/project/show/home:wonko:sfos
1 Like
it is not a good idea to install old outdated combi packages by downgrading openssl, it is a good idea to install openssl 1.0.2 legacy (JollaPhone & X & XA2) | OpenRepos.net — Community Repository System to have newest jolla openssl1.1.1 installed along with updated legacy openssl1.0.2 fixing CVE-2018-5407 CVE-2020-1968 CVE-2020-1971 CVE-2021-23840 CVE-2021-23841 and CVE-2021-3712
2 Likes