openssl 1.1.1
Provides: libcrypto.so.1.1
Requires: glibc >= 2.17 (any SFOS version since Jan'2014)
These are the original RPM files by Jolla from Sailfish OS 4.3.0
These RPM files allow to install OpenSSL 1.1.1 on Sailfish OS releases before 4.3.0.
It was succesfully tested on a Jolla1 running SFOS3.4
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.
Any armv7-Device running SFOS 3.4 or less (e.g. every Jolla1...) needs the old version https://openrepos.net/content/lpra7/openssl-102-legacy-jollaphone-x-xa2 (with storeman/warehouse this will happen automatically) in addition to the new version provided here.
If you want to manually install this on SFOS 3.4 or before: DO NOT USE pkcon , use rpm or zypper instead
pkcon will break your system
sha256sum filename:
c0f7693b25d03144c1ba62c5a63bbec25d1011024c9150991e26e761674dfa43 openssl-1.1.1l+git1-1.10.4.jolla.armv7hl.rpm
26c6f113db072c76738efc3e3e5ea789d892aa6bb7c2b28b4de01cb4b839d4ff openssl-devel-1.1.1l+git1-1.10.4.jolla.armv7hl.rpm
9d8216c193cd39f920d71606dc58ccafad45c088601e4ef6c2eddf7f08fe90af openssl-libs-1.1.1l+git1-1.10.4.jolla.armv7hl.rpm
25737ffff83b0de794189747a740b2361a5d8874c97977e9461b445001a90cc6 openssl-1.1.1s+git1-1.10.2.jolla.armv7hl.rpm (original jolla rpm converted to not use zstd)
8ba89972e68995785b01afec1b3542e1addc01260dbd67f90fb997f1b4970b1b openssl-devel-1.1.1s+git1-1.10.2.jolla.armv7hl.rpm (original jolla rpm converted to not use zstd)
88bd95de85b549ea364433c189ec8ef6954cd5933cfa679aefb61b1688fbe449 openssl-libs-1.1.1s+git1-1.10.2.jolla.armv7hl.rpm (original jolla rpm converted to not use zstd)
30f5f2c63f28943f57f080c1863884404a2199a71248e3347cdb9f120c1d809e openssl-1.1.1v+git1-1.11.4.jolla.armv7hl.rpm
67418c36dd0603d0fd639323da1b626659d2678108b8dd68133c03f8dde25c53 openssl-devel-1.1.1v+git1-1.11.4.jolla.armv7hl.rpm
b1c6513d73a8d3c7878982200518a2cacfb9fb8ef4b94fc789ef87f7081847e6 openssl-libs-1.1.1v+git1-1.11.4.jolla.armv7hl.rpm
d79a119ea6d2fc5b88482ea56c14317e6f5575ef2588fc5eb42fe5be0bfe6ce7 openssl-1.1.1k+git1-1.7.4.jolla.i486.rpm
e10449f30be58c69d199b0e489a28f33cfba8fadfba28260e1001fb4b45d8ba7 openssl-1.1.1l+git1-1.10.4.jolla.i486.rpm
16f416f5987a8d04eec3ad9ef7ccb9d8e2ffc37b1d3cf89733000a2a9d1aab36 openssl-1.1.1l+git1-1.10.4.jolla.aarch64.rpm
54d650c50d8e2f445e3a19849a16b07a6e3baee06fc58be12708947b52b2f4e9 openssl-devel-1.1.1k+git1-1.7.4.jolla.i486.rpm
e580a42408d072858c21e53dc37d04520cdf9a519c294f6028ddee2f71ff7266 openssl-devel-1.1.1l+git1-1.10.4.jolla.i486.rpm
cfdb9f7b4103f62a7003cfdb71897e483680a62abe98df1dee961d51a2ff5fec openssl-devel-1.1.1l+git1-1.10.4.jolla.aarch64.rpm
de8286c062039fa1cc1af7744942409a8514617c9e0ba95fc8ab8d0387173a50 openssl-libs-1.1.1k+git1-1.7.4.jolla.i486.rpm
70028434836401767da856ed801bb6f53bd3323450a3154c0a3265db4ab16614 openssl-libs-1.1.1l+git1-1.10.4.jolla.i486.rpm
b982174a56c7ab13130181701892d126e71ebcd70a5e94f1c6d930018161a510 openssl-libs-1.1.1l+git1-1.10.4.jolla.aarch64.rpm
Category:
Application versions:
Comments
delocoyo
Mon, 2021/11/22 - 10:57
Permalink
So we might install, unistall the repositories and the apps or what? All is getting confuse
lpr
Mon, 2021/11/22 - 13:13
Permalink
hm, I don't know exactly what you are referring to, but yes you can install OpenSSL1.1.1 here with any device
lpr
Tue, 2021/11/16 - 02:21
Permalink
hm https://openrepos.net/users/hengyedev keeps deleting my comments about statically linking openSSL this guy has something to hide, it seems
slava
Tue, 2021/11/16 - 18:34
Permalink
...or because you're being too noisy. Unmaintained doesn't mean broken.
My opinion is that messing with dynamic openssl libraries is more likely to cause trouble or even break your system than running an app statically linked with OpenSSL 1.0. But I'm not going to argue with you and further increase the amount of noise, just leave this comment here for the record.
lpr
Wed, 2021/11/17 - 03:58
Permalink
well, CVE-2018-
5704-5407 CVE-2020-1968 CVE-2020-1971 CVE-2021-23840 and CVE-2021-23841 at least seems pretty broken... the statically build can't even get my fixed version of 1.0.2oslava
Wed, 2021/11/17 - 03:46
Permalink
OK, I checked the first one. The summary goes like this:
Open On-Chip Debugger (OpenOCD) 0.10.0 does not block attempts to use HTTP POST for sending data to 127.0.0.1 port 4444, which allows remote attackers to conduct cross-protocol scripting attacks, and consequently execute arbitrary commands, via a crafted web site.
What does that have to do with with libcrypto? With an app which doesn't even access the network? An app which which doesn't even link libssl statically or dynamically? Come on. I suspect that the other ones are similar corner cases, mostly if not exclusively related to libssl.
Not to mention that accessing a crafted web site from an On-Chip Debugger sounds like a slightly crazy scenario :)
You just made me feel even more confident in OpenSSL 1.0
lpr
Wed, 2021/11/17 - 03:59
Permalink
I think you never ever made a typo: CVE-2018-5407
slava
Wed, 2021/11/17 - 05:31
Permalink
Simultaneous Multi-threading (SMT) in processors can enable local users to exploit software vulnerable to timing attacks via a side-channel timing attack on 'port contention'.
That's libssl too.
olf
Mon, 2021/11/15 - 20:52
Permalink
Oh @lpr_A7, I just realised that you do replace "system RPMs" in a common repository.
Please read this thread for a long and detailed explanation, why this is fundamentally wrong, or the third bullet point in these notes for a short one.
I.e., please move these packages to a separate repository (probably together with OpenSSL 1.0.2) from your common one.
lpr
Wed, 2021/11/17 - 03:25
Permalink
hm, I don't know the point. All my packages are system packages, there is no "app" or something, so it is a separate repository
> should be disabled at all times
please remove that, it is wrong for lpr, lpr_A7
olf
Sat, 2021/11/20 - 15:43
Permalink
> hm, I don't know the point.
Obviously. And still.
Please try to understand the point by following the links I provided, which leads to a detailed description, what is technically happening and why this is evil to do (because users will not and should not need to understand it).
IMO it is the responsibilty of anybody who offers software here as a repository maintainer to not enable the users to break their SailfishOS installations easily.
While your libmpg123-0 package from this repository of yours (lpr_A7) caused one problem, it now turned out that your gstreamer-1.18.5 package from your lpr repository caused another problem.
Please understand that this cannot work with Jolla's (originally Nokia's) SSU, because it supports no repository priorities (all are at 99) and no repository pinning.
Thus, because all your "packages are system packages", you shall put them into separate repositories, for each of the package groups you are providing.
Additionally you should thoroughly consider what happens on SailfishOS upgrades, when Jolla provides a new version of the packages you did replace, either with a higher or a lower new version number than yours. Then document how a user should handle that for each of your package groups = repositories.
All three of your current repositories (lpr, lpr_A7, lpr_next) share the same basic issue, causing broken SailfishOS installations (when upgrading, but potentially already earlier), which an average user can only fix by reflashing.
P.S.: Please calm down your tone: Shouting (in all caps) and "*facepalm*" are not approriate reactions when someone repeatedly tries to explain the havoc you are causing and how to avoid it.
lpr
Sat, 2021/11/20 - 17:41
Permalink
I read it, and as I already said, I don't get it:
on my Jolla1 every SFOS update installed the Jolla-versions of the system-packages, so I had to switch back to mine every update again (not automatically). The SFOS-update-process has a list of packages to install and that are the Jolla-ones
> While your libmpg123-0 package from this repository of yours (lpr_A7) caused one problem, ...
No, Jolla caused the inconvenience because it named the package differently to the existing ones here. But having libmpg123-0 parallel to libmpg123 causes an install error because of file-conflicts, you cannot install it without force. But I already removed the package when reading on forum.sailfishos.org...
the other 'failed to load plugin' messages are normal, because he has not installed the proprietary plugins...
P.S.: {they are still there , It is obvious ... that it is your xyz-package causing this , amount of denial } are not appropriate too and yes, discussion should be calmed down, I agree.
olf
Tue, 2021/11/23 - 05:18
Permalink
> I read it, and as I already said, I don't get it:
This is unfortunate. Primarily for the users of your repositories.
> on my Jolla1 every SFOS update installed the Jolla-versions of the system-packages, so I had to switch back to mine every update again (not automatically). The SFOS-update-process has a list of packages to install and that are the Jolla-ones
While it is correct that "the SFOS-update-process has a list of packages to install", it always ended up updating all packages from all repositories when upgrading SailfishOS (both, at the GUI and TUI), for me and many others (at least on all SailfishOS releases < 3.4.0). This is also the behaviour of zypper dup and pkcon upgrade-system, with which in mind version --dup seems to be designed.
For example having NielDK's rich repository (which I loved for the vast amounts of stuff he provided) enabled during a SailfishOS upgrade (back in the old days, 2014 / 2015, SFOS 1.0.x / 1.1.x) always resulted in a severely broken SailfishOS installation.
> No, Jolla caused the inconvenience because [irrelevant technical details omitted]
Sorry, no: We are using SailfishOS, hence Jolla is always right! It is their product and it works how they design it, including all (the many) flaws, permanantly changing structural decisions (e.g., the SD-card path) etc. They will not listen to any of us, thus arguing on technical grounds is futile.
Hence no "but if only Jolla would provide repository separation mechanisms ("pinning") or at least working repository priorities, then I could handle this properly", as they don't; likely they never will, because they do not care, as it is working for them (and their single significantly paying customer).
Hence the only feasible way was and currently is to use separate repositories per package group, until Jolla introduces any of the "modern" mechanisms the big Linux distributions provide for many years; or at least explain and document how the minimalistic mechanisms they introduced with SailfishOS 3.4.0 work.
lpr
Tue, 2021/11/23 - 14:04
Permalink
> unfortunate...
no it's all right after deleting libmpg-0 packages
>While it is ...
You explain the behaviour of zypper up , this updates all packages with higher version available, zypper dup makes upgrades and downgrades...
>Sorry no, ...
Jolla is not always right, because if Jolla decides to add a package to SFOS already existing here, then they should not create a mess and add obsoletes and conflicts to their specfile
AND
not having the so-file version in packages name is so wrong as it always breaks backwards compatibility because one cannot easily install two packages with same name and different version
olf
Wed, 2021/11/24 - 01:55
Permalink
Sorry, I see it is futile trying to communicate anything not 100% technical to you.
And even communication about most of the technical stuff fails, e.g. describing what Jolla's upgrade mechanisms do in practice is answered with an excurse about zypper, which is not the tool they use.
And insisting that Jolla is "so wrong" about some stuff (which is even technically true for a good part) and rather should do things the way you state here at Openrepos (I would be glad if they would listen to you, but that is never going to happen) makes it obvious for me that you live on a different world than I do.
Jolla is right about everything in SailfishOS (by definition), until they re-define something as wrong. Simply because it is their Linux distribution, not yours! Your (and my) role is to be a consumer of their product.
slava
Wed, 2021/11/24 - 03:36
Permalink
I think you're being too radical here. Jolla does need the community, and community does need Jolla. Who needs whom more is debatable. But it's clearly a two-way relationship.
Disclaimer: I am affiliated with Jolla, but my activity here at OpenRepos is not directed by Jolla in any way. My own opinions expressed here must not be interpreted as Jolla's official position.
olf
Wed, 2021/11/24 - 04:02
Permalink
I disagree, especially WRT the topic lpr is addressing: Technical design decisions.
Actually everything but testing and providing feedback on this seems to be not really wanted by Jolla from any outsider, in contrast to e.g., Suse or RedHat / Fedora.
Recent, typical example: https://github.com/sailfishos/gnutls/pull/1#issuecomment-973795165
Seen that many ten times in the past 7 years: Some discussion & change requests by sailors and then either "you and your work are dismissed" or eternal silence.
From my PoV contributions never have been welcomed.
slava
Wed, 2021/11/24 - 06:47
Permalink
AFAIK GnuTLS topic is poisoned by some licensing/legal issues, which makes it a bad example. But I have to agree that some serious turns are being taken without much discussion, even internally. There's that. Collaboration is far from being perfect.
olf
Fri, 2021/11/26 - 03:51
Permalink
> Collaboration is far from being perfect.
Yes, and it has become even worse the last couple of years, on the social level (Ville's latest statments on the censoring thread just made me speechless), though a bit better at specific technical points, but not on others. So all in all this is spiralling down year after year IMO.
(BTW, thank you for being so open about that, but pay attention to not regret it. There must be a reason, why most sailors are so tight-lipped and maybe this also contributed to James Noori's departure at the start of 2020.)
> AFAIK GnuTLS topic is poisoned by some licensing/legal issues, which makes it a bad example.
No, the "some licensing/legal issues" is always the same single one: (L)GPLv3
I have (documented) much understanding for regarding the (L)GPLv3 as problematic, but there is no escape for Jolla, because they cannot replace every component which switched to (L)GPLv3 by a different one and they cannot keep distributing outdated, security-bugged versions forever (especially Qt 5.6). One can only go for that (strategy), if one has resources similar to Google or Apple (which are both doing that).
And it makes SailfishOS an technically awkward, strangely different Linux distribution, diverging more and more from the big ones like RedHat / Fedora, Ubuntu and SUSE.
This is an dead end strategy Jolla has chosen; the Qt version used already shows that clearly.
IMO there is practical way out of the (L)GPLv3 dilemma: Do not use such software for packages the user shall never be allowed to exchange in an MDM scenario. But that would mean to proactively deal with that issue (and the customer being afraid of it), instead of choosing a pure avoidance strategy out of fear.
slava
Fri, 2021/11/26 - 05:28
Permalink
I share some of your sentiments but sorry, it's not something I feel like arguing about. I like writing code and making it work the way I want to))
olf
Sat, 2021/11/27 - 18:00
Permalink
That is understandable and fine for me (not arguing).
Thank you for this conversation.
Happy coding!
olf
Wed, 2021/11/17 - 00:22
Permalink
And your repository here is already causing great mishaps.
lpr
Wed, 2021/11/17 - 03:17
Permalink
I already had removed those packages (btw mpg123 was NOT part of SFOS at the time this packages were created so their name was libmpg123-0 with so-version in name and jolla came later and named it libmpg123, well). It is not easy to tell why that happened, he had other repos too (openrepos-kravich). In normal condition he cannot install 2 different packages with same files without abort through error
olf
Wed, 2021/11/17 - 17:07
Permalink
=> This is why you must use a separate repository for each set of packages, which replace system packages.
I am surprised by the amount of denial, and wonder why.
lpr
Wed, 2021/11/17 - 18:37
Permalink
1)I HAVE REMOVED libmpg-0 (1.23 and 1.25) they are not still there
2) ABSOLUTELY WRONG: he now installed jolla-libmpg123-1.25 only and it does not work
3) *facepalm*
olf
Mon, 2021/11/15 - 20:52
Permalink
@lpr_A7, while it was slightly amusing to read @slava's confusion, I have to admit that I also did not fully comprehend the how, why, from where and what for!
IMO he is absolutely right about the necessity to properly document, …
Suggestion: These are the original RPM files by Jolla from Sailfish OS 4.3.0
Suggestion: These RPM files allow to install OpenSSL 1.1.1 on Sailfish OS releases before 4.3.0.
It also would be very helpful to document on which Sailfish OS releases these have been tested (at least 3.4.0 AFAIU).
Hence please eliminate the "(JollaPhone)" from the title, because they are helpful for any other hardware running a Sailfish OS release before 4.3.0, too.
And also upload the RPMs for other architectures (i486 and aarch64); I recently documented how to download any RPM for any architecture from any Sailfish OS release at FSO (use chapter B, section 1 there).
Even with your recent addition of a build log and a source tar.gz as RPMs (!) this is so intransparent, that I would be inclined to believe there is something to hide, if I was not aware of the context (you being around for long etc.). The tar.gz dump is not helpful at all, because you do not document, how this source tree was created (i.e., where it originated from, how it was patched / what to diff it against).
The proper way is, as @slava suggested, to "fork" the original repository and apply your patch set as commits: That is easy to see, understand and trace.
Or does really something prevent their installation and use on an Xperia 10 or a Jolla C / Intex Aquafish?
Hence do eliminate the "(JollaPhone & X & XA2)" from the title.
And please also compile these RPMs for other architectures (i486 and aarch64) to cover the Jolla Tablet and Xperia 10 II, too.
I really appreciate your efforts, but they are curently presented and documented so confusingly that anyone sane will at least hesitate to install a crucial crypto-library under these circumstances.
Side note: The fact that the comments are switched off for the "openssl 1.0.2 legacy (JollaPhone & X & XA2)" page without denoting where to alternatively comment and ask, does contribute to this impression.lpr_A7
Sat, 2021/11/13 - 18:24
Permalink
I don't know if a JollaC/aquafish can handle -mcpu=cortex-a15 . So some user may try it and tell me.
there should be no aarch64 before SFOS4.0...
and I will try to download the rpm-files for other architectures (your link): how do I tell zypper to download i486.rpm , it only says no package: openssl [disabled armv7hl and added i486-jolla-repo]
side note: comments have not been switched off, are not switched off and won't be switched off at 1.0.2 legacy, they are open
olf
Mon, 2021/11/15 - 20:49
Permalink
@lpr_A7, thank you for your reply and changes to the descriptions of your two OpenSSL repos.
aarch64 is suppported since SailfishOS 4.1.0, but OpenSSL 1.1 only since SailfishOS 4.3.0: Thus please provide the packages for aarch64 and i486, too.Suggestion: Please cross-link your two OpenSSL repos; as they already mention each other, just make that text clickable.
lpr_A7
Sun, 2021/11/14 - 20:57
Permalink
- OK
- no, AFAIK openSSL1.1 is standard since SailfishOS 4.0 so there is no package linked against OpenSSL1.0 (aarch64)
- no problem
- ok, should be there
Suggestion: hm, there is only one repo:
on a Jolla1 the legacy package should be installed automatically/simultaneously because it cannot live without 1.0.2 on any other device the two packages are not connected
olf
Mon, 2021/11/15 - 20:25
Permalink
> Suggestion: hm, there is only one repo:
Oh yes, sure.
What I meant is to cross link the two application pages, i.e.:
Furthermore (as already denoted) this is device independent, so better phrase it "have a pre-SailfishOS 4 installation and want to use openssl 1.1.1".
Thanks!
Pages