If you have a legacy app that needs libcrypto.so.10 and updated to SFOS4.3+ or you have a Jolla1 and want to use openssl1.1.1 but system libraries use openssl1.0.2 you need this compatibility version of the old unsupported and not recommended openssl1.0.
Provides the pre SFOS4.0 libcrypto version.
J1 users note: when using storeman/warehouse the very first step is to install https://openrepos.net/content/lpra7/openssl-111 (1.0.2 legacy here will be installed automatically simultaneously)
when using downloaded local files: you need to install both (legacy 1.0.2 and 1.1.1) in a single step: e.g. zypper in [file1.rpm] [file2.rpm]
The OpenSSL toolkit provides support for secure communications between
machines. OpenSSL includes a certificate management tool and shared
libraries which provide various cryptographic algorithms and
protocols.
Requirements: glibc >= 2.17 (any SFOS version since Jan'2014) and Jolla1 , X , XA2 or Xperia 10
It was succesfully tested on a Jolla1 running SFOS3.4
It may work on JollaC or aquafish Devices, too. But this is not tested.
sha256sum filename:
0aa6a9c5de62c4946ccffd9c3829ea45ca16c426c52f70a391c86e6e2fca414f openssl-libs10-1.0.2o-5.armv7hl.rpm
156766bd40f40c5c7b3bb021cd6c3da2be7a44e631b080f358eef7398e0fc023 Built_log.tar.xz.rpm
7ea84bb4f46ddc50ef848a8a2a30396c1d1fc3f59e59bd45b3d4c02857f572cc sources.tar.xz.rpm (https://github.com/sailfishos/openssl/archive/refs/heads/upgrade-3.2.1.zip + large-file-support (SFOS3.4) + applied-jolla-patches with quilt because the way in the spec-file did not work)
Attachment | Size | Date |
---|---|---|
sources.tar_.xz_.rpm | 3.98 MB | 10/11/2021 - 15:57 |
built_log.tar_.xz_.rpm | 50.25 KB | 10/11/2021 - 15:59 |
openssl-libs10-1.0.2o-4.armv7hl.rpm | 857.04 KB | 23/12/2021 - 01:10 |
openssl-libs10-1.0.2o-5.armv7hl.rpm | 857.89 KB | 23/03/2022 - 02:39 |
1.0.2o-3 fixes: CVE-2018-5407 CVE-2020-1968 CVE-2020-1971 CVE-2021-23840 and CVE-2021-23841
1.0.2o-4 fixes: CVE-2021-3712
1.0.2o-5 fixes: CVE-2022-0778
Comments
olf
Sun, 2021/11/14 - 17:56
Permalink
Please provide an RPM for i486, too.
Also I (@slava, too) would appreciate very much, if you provide a traceable / compehensible path from the original source to the RPMs here.
For details, see fourth bullet point of this comment.
lpr_A7
Sun, 2021/11/14 - 21:03
Permalink
for i486 I uploaded original OpenSSL1.1.1k packages from Jolla here: https://openrepos.net/content/lpra7/openssl-111
it contains 1.0.2 inside but suffers CVE-2021-3712 and CVE-2021-3711
olf
Mon, 2021/11/15 - 21:05
Permalink
Ah, these packages from Jolla contain both, OpenSSL 1.1.1 and 1.0.2, correct?
So you avoided building OpenSSL 1.0.2 for i486 this way, correct?
Still this does not provide a tracable way to the RPMs offered here.
I would be happy to be able to review the changes you applied, which you vaguely described as "Spec file was edited to move conflicting files to the devel-package which is not provided here."
lpr
Mon, 2021/11/15 - 23:44
Permalink
yes, but these "ugly" combi-packages from jolla are the beginning of all evil, they should have made 2 Packages - individually installable - out of it (like some distros do) since SFOS3.4 (I think they had the plan to go to 1.1 at this time) and don't leave J1 users (and all others running old apps) back this way...
openssl is not really tracable:
- jolla stopped at 1.0.2o with no reason
- there is 1.0.2v at https://github.com/openssl/openssl/tree/OpenSSL_1_0_2-stable
- but there is 1.0.2y available when you have premium account behind paywall (see fix for CVE-2021-23840 in latest upload)
so I will just refer to https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/openssl/1.0.2... for this release
- to the first upload: the code is 100% the jolla release-3.2.1 one.
the jolla-patches (in the debian/patches/series file) were applied by quilt (that created the .pc directory) and the two separate files ec_curve.c and ec_test.c were moved manually to crypto/ec/
in the .spec-file: I moved
%dir %{_sysconfdir}/pki/tls
%dir %{_sysconfdir}/pki/tls/certs
%dir %{_sysconfdir}/pki/tls/misc
%dir %{_sysconfdir}/pki/tls/private
%config %{_sysconfdir}/pki/tls/openssl.cnf
to the %files (so the bin-package and not the devel -- sorry my mistake) and I changed the name of the libs-package to libs%{soversion} and added:
touch /tmp/openssl.cnf
export OPENSSL_CONF="/tmp/openssl.cnf"
to avoid build errors like:
Error configuring OpenSSL
1085682912:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(libssl_conf.so): libssl_conf.so: cannot open shared object file: No such file or directory
1085682912:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:233:
1085682912:error:0E07506E:configuration file routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:273:module=ssl_conf, path=ssl_conf
1085682912:error:0E076071:configuration file routines:MODULE_RUN:unknown module name:conf_mod.c:214:module=ssl_conf
Error configuring OpenSSL
1085682912:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(libssl_conf.so): libssl_conf.so: cannot open shared object file: No such file or directory
cmp: EOF on ./p.clear
make: *** [Makefile:223: test_enc] Error 1
make: Leaving directory '/home/mersdk/openssl/test'
error: Bad exit status from /var/tmp/rpm-tmp.ngk0y8 (%check)
olf
Thu, 2021/12/23 - 05:56
Permalink
> jolla stopped at 1.0.2o with no reason
I suppose their usual lack of resources and no significant bugfixes / features as the reason.
> there is 1.0.2v at https://github.com/openssl/openssl/tree/OpenSSL_1_0_2-stable
Well, I see 1.0.2u as the last stable release, 1.0.2v is marked as "devel".
> [...]
Thank you for you efforts. While it all sounds reasonable and I do believe you are having good intentions, this is not what I thought of when writing "traceable".
As I do understand that this is a bit tricky, given the state of the OpenSSL sources (the original ones and the ones from Jolla), I resorted to uploading the last version of Jolla's combi-packages for all architectures (armv7hl, aarch64 and i486) in a proper manner. "Better safe than sorry!"
slava
Sun, 2021/11/14 - 19:47
Permalink
I ended up doing this i.e. loading libcrypto dynamically. Trying libcrypto.so.1.1 first and then libcrypto.so.10 if 1.1 is not found. They do seem to be binary compatible, at least the API which I'm interested in.
Hoxifi
Thu, 2021/11/11 - 08:50
Permalink
Hi, can you provide aarch64 version too?
lpr_A7
Sat, 2021/11/13 - 18:19
Permalink
why? What for? Who should need that? Most likely not.
lpr
Thu, 2021/11/11 - 03:56
Permalink
comment test