openssl 1.1.1

Rating: 
2.77778
Your rating: None Average: 2.8 (9 votes)

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.

 

Requirements: glibc >= 2.17 (any SFOS version since Jan'2014)

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 Jolla1 user who wants to install an app that needs libcrypto.so.1.1 needs this libraries in addition to the old version https://openrepos.net/content/lpra7/openssl-102-legacy-jollaphone-x-xa2 (with storeman/warehouse this will happen automatically).

 

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

d79a119ea6d2fc5b88482ea56c14317e6f5575ef2588fc5eb42fe5be0bfe6ce7  openssl-1.1.1k+git1-1.7.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
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

Application versions: 

Comments

delocoyo's picture

So we might install, unistall the repositories and the apps or what? All is getting confuse

lpr's picture

hm, I don't know exactly what you are referring to, but yes you can install OpenSSL1.1.1 here with any device

lpr's picture

hm https://openrepos.net/users/hengyedev keeps deleting my comments about statically linking openSSL this guy has something to hide, it seems

slava's picture

...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's picture

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.2o

slava's picture

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's picture

I think you never ever made a typo: CVE-2018-5407

slava's picture

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's picture

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's picture

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's picture

> 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's picture

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...

mpg123_param2 is a defined symbol: https://www.mpg123.de/api/group__mpg123__init.shtml#gac656378d8d50cec62940dd30c901809a

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's picture

> 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's picture

> 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's picture

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's picture

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's picture

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's picture

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's picture

 > 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's picture

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's picture

That is understandable and fine for me (not arguing).
Thank you for this conversation.

Happy coding!

olf's picture
lpr's picture

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's picture
  1. You have not removed them (e.g. libmpg123), they are still there!
  2. It is obvious from the FSO thread that it is your libmpg123-1.29.1 package causing this.
  3. People installing any other package from your repository will also be affected by this when they upgrade SailfishOS.
    => 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's picture

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's picture

@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, …

  • where exactly the files in this repository "openssl 1.1.1 (JollaPhone)" are coming from.
    Suggestion: These are the original RPM files by Jolla from Sailfish OS 4.3.0
  • what these files can be used for.
    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).
  • that these RPM files are not linked to any specific hardware.
    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).
  • where exactly the files in the "sister" repository "openssl 1.0.2 legacy (JollaPhone & X & XA2)" are coming from.
    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.
  • that these RPM files in the "sister" repository are not linked to any specific hardware.
    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's picture

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's picture

@lpr_A7, thank you for your reply and changes to the descriptions of your two OpenSSL repos.

Suggestion: Please cross-link your two OpenSSL repos; as they already mention each other, just make that text clickable.

lpr_A7's picture

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

https://sailfish.openrepos.net/lpr_A7/personal/main

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's picture

> Suggestion: hm, there is only one repo:

Oh yes, sure.
What I meant is to cross link the two application pages, i.e.:

Thanks!

Pages