SSL Update Errors on Linux

So running Ubuntu 20.04 and 20.10 I have the issue continuing to show up. I know in past topics you’ve mentioned the difficulty with varying libSSL installs, but could you possibly statically link the appropriate lib during compile so you don’t have this issue? I know other software does this and I’ve had to statically link some of my binaries and libraries to avoid the issue described.

1 Like

I have this same issue, been dealing with it for almost two years. Since it seems to only affect the “Check for Updates”, I haven’t been pressing it, and I don’t know how many Ubuntu users you have out there… so it may also be a “Bang for the Buck” issue.

libssl is a strange beast. I’ve looked into statically compiling it but, even if Qt would let us do it the way we are using it now (it won’t), it could still cause problems on some linux systems because of where it looks for various SSL certs on the system. Basically the libssl version needs to match the directory structure it expects for where to find certs. This is further complicated by the fact that the version of Qt we are using is compiled on Red Hat Enterprise Linux which seems to believe standard cert locations is for other linux distros - I’m drastically oversimplifying and spent a ton of time digging into this about a year ago and it just really didn’t end up being worth further investigation.
For one: I’ve had the update check work fine on the latest Ubuntu releases - but then sometimes, like you’ve found, it doesn’t. It’s a bit of a moving target.

@shipmodeller nailed it on the head: it’s not really worth further dev time for a very small sub-set of users especially when the only thing it prevents is automatic version checks.

I’ve struggled with this myself. So, the problem is that it looks bad when something fails. May I suggest that detect that it fails, and give them the option to remove the “Check for new versions” from the menu. You can ask that they can enter their email address and get a notification when there is a new version released. If at future time, this gets rectified, by either inclusion of binaries that work, or perhaps a different method of detecting new versions, you can re-instate the menu option. Still not a one hour fix… but better than continuing to look bad to end users. I know I tried to get this fixed via LightBurn year or two ago, and it is still annoying on such a wonderful product. …

I’m not sure if it’s fair to say “a small subset”. Do you have anyway of quantifying this? Industry trends are showing that Microsoft is doing a wonderful job of getting users to go elsewhere, plus they’ve very much stated that Windows on the desktop is not the long term future of Microsoft.
With that, I would never do any development on RHEL, it’s purposefully kept behind and requires a lot of backports. That does explain a lot. I would say use CentOS if you want the Red Hat ecosystem, but we know how that’s not got a future now either.
In any case, here’s a good forum post about some folks having issues statically linking libssl to Qt and how they resolved it.
So many Qt applications are cross-compile on RHEL, Ubuntu (and variants), Arch, MacOS, and Windows and don’t have the same issues with libssl. I understand you feel that it’s a small subset of users, but that’s still a subset of users that will find other alternatives and not give good feedback. Every user that gives you money counts, and to say “a small subset of users isn’t worth it” really makes no sense, from a developer standpoint. I would never, and have never done that with anything I’ve developed or designed.
Just to add, a good CI/CD pipeline would allow you to build against a number of targets without any added effort.

We have analytics for which versions everyone uses. Windows is 83%, MacOS is 16%. Linux is “the rest”, IE just over 1%. Given that not all Linux distributions suffer the issue, it would be more correct to say it’s a very small subset of our users.

1 Like

I used to have the SSL update error also, but someone here posted a “fix” that worked for me.
Not sure, but I think it was Adams response in post #7 of this thread:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.