Meepasswords crashes on 4.3.0: OpenSSL / libcrypto 1.0 is missing

It seems that the new release makes Meepasswords to crash when trying to log in to the app. If run from terminal it says “Segmentation fault (core dumped)”.

Has anyone got a clue what could cause this problem and if it could be fixed?

The one thing I can imagine is that meepasswords is built against openssl 1.0 which is now replaced in 4.3.0 by openssl 1.1!

You may try an ugly workaround and symlink

ln -s /usr/lib/ /usr/lib/
ln -s /usr/lib/ /usr/lib/

You know you (may) need qca-qt5, openrepos/piggz?

Well the APIs were altered between OpenSSL 1.0.x and 1.1.x (that is actually why the minor version is different), so that likely does not work.

Thus I decided to provide the last “OpenSSL 1.0 & 1.1 combi-RPMs” from Jolla (in SailfishOS 4.2.0) at Openrepos for a convenient installation.
As usual, do read before acting!

You will also find self-compiled, “split” packages (i.e., separate RPMs for OpenSSL 1.0 and 1.1) at Openrepos, which I originally considered to use, but the answers to a few checks & balances questions convinced me that I do not want to take the risk and that I will never enable that repository.
Again, do read (specifically the long comment threads) thoroughly before acting!


Thanks, I hadn’t noticed the whole openssl change thing. I managed to get it working with those links and installing this package that was mentioned in other thread:

1 Like

Yeah, thanks for the reply. This was just my older phone that had some entries that I hadn’t yet moved to my new pw manager. So there wasn’t much worry about breaking stuff, and any hack was applied :slight_smile:

So then you should mark @olf’s answer as solution!

I was not aware of that repo :face_with_monocle:
Great stuff.

But -and I feel prepared to get another clap-on-head-answer :wink: - would it not suffice to pack only the older 1.0 libs and provide them as single rpm as future-proof workaround, only as I do not expect majority of old apps (e.g. MeePasswords just one version provided from 2014) to be maintained anymore and recompiled against 1.1?

1 Like

“Stuff”, i.e. your SailfishOS installation, may break when upgrading SailfishOS after the installation of “system RPM replacing RPMs”! :stuck_out_tongue:
And your SailfishOS installation will very likely break when having a repository with multiple “system RPM replacing RPMs” enabled while upgrading SailfishOS (as discussed multiple times at TJC, Openrepos and FSO). :scream:

This is the subtle effect of “not understanding what one does”, the wrecking havoc comes much later, but people do not understand it was only themselves enabling a repository of a repo-maintainer, who does not care (lachs0r, NielDK, lpr* etc.).
This is why regularly the advice is provided to disable all Openrepos repositories before upgrading SailfishOS, although these ill effects are only caused by a few repositories.

I “packed” nothing, Jolla did: As described there, I simply downloaded their packages and uploaded them at Openrepos.

But I pondered a while how to handle that best, after the lengthy discussions with lpr at multiple places (FSO and Openrepos):

  • Slava’s input and lpr’s answers to my questions convinced me not to trust any OpenSSL packages, which are not recompiled in a 100% transparent and automatised way, e.g. by a GitHub or Gitlab CI-pipeline.
    Mind, that OpenSSL is a central cryptography provider (libcrypto) and network security provider (the rest of openssl-libs).
  • The same applies to the source code, which IMO must be git-cloned from OpenSSL’s official git repository (either their original one or their own clone at GitHub) in a transparent (i.e., prove-able) way, see
  • And this transparency principle also applies to the packaging process, which can also dealt with as part of a CI/CD-pipeline.

So, what do you try to communicate per “would it not suffice …”? :wink:

  • Typing this reply is approximately the same amount of work that I invested into creating the repository we discuss!
  • I just intended to create a viable, safe, transparent and easy to handle alternative for me and others compared to lpr’s work, which turned out (by Q&A) to be too opaque (“intransparent”) and convoluted for me (and his three repositories outright dangerous to enable, IMO).
  • Recompiling and repackaging is nothing I have or will consider, because doing this properly requires some efforts.
  • I explicitly stated that these packages provide an quick, easy and clean solution, specifically for updating OpenSSL on SailfishOS < 4.2.0 to the latest “combi-RPMs”.
    I.e., on SailfishOS < 4 one also gains OpenSSL 1.1 support!
  • I also explicitly stated that these packages provide an quick, easy and clean provisional solution for SailfishOS > 4.2.0, but “still you should contact the author of [the affected] apps and ask kindly for an update, which uses OpenSSL 1.1”!

Feel free to take aforementioned transparency requirements into account and

to pack only the older 1.0 libs and provide them as single rpm as [a] future-proof [solution].

Happy hacking!

It does not make any sense to create the links first and then install the package:
The links will be overwritten, when you install any openssl-libs-1.0 RPM or a OpenSSL (-libs) 1.0 & 1.1 “combi-RPM” (which contains openssl-libs-1.0, including and


thanks a lot all for supporting each other. :smiley:
It is great to see that MeePasswords is still being used. :slight_smile:

I already posted it in another thread that I uploaded new builds for MeePasswords and for supporting it qca-qt5:

I hope mentioning the other post here is OK. I just want to make you aware of the new builds as well.

Unfortunately, I do not have access to a SailfishOS device and thus could not test the new builds.
So, please be very cautious when you try the new builds and make backups before trying the new builds.

I hope the new builds are helpful.




It works now also on Sony Xperia 10ii with SFOS Great work! Thanks