Cannot open project file created with Openshot 2.4.4 on Debian 10

[cometchaserde]

Describe the bug
Cannot open Openshot.osp created with Openshot 2.4.4 on Debian 10

To check if it is a problem, I created an new project with a video + music file with Openshot 2.4.4 and saved it. Next I tried to open it with Openshot 2.5.0.

Openshot doesn't open the file. Openshot 2.5.0 just crashes. It happens also with the latest build.

Expected behavior
Open the project file

System Details

• OpenShot Version: 2.5.0
• libopenshot Version: 0.2.4
• Platform: Linux-4.19.0-6-amd64-x86_64-with-debian-10.2
• Processor:
• Machine: x86_64
• Python version: 3.4.3
• Qt5 version: 5.2.1
• PyQt5 version: 5.2.1
• Qt Detected Languages: ['de-DE']
• LANG Environment Variable: de_DE.UTF-8
• LOCALE Environment Variable:
• Daily Build Installed: http://github.com/OpenShot/openshot-qt/releases/download/OpenShot-v2.5.0-dev1-1582091950-fe8ea216-836e49fa-x86_64.AppImage

Log Files

• http://logs.openshot.org/lcgdtynpdkibq06yguwirjn9457pblug/openshot-qt.zip
• http://logs.openshot.org/lcgdtynpdkibq06yguwirjn9457pblug/libopenshot.zip

Exception / Stacktrace
No stacktrace found in log files

Screenshots (Optional)
If applicable, add screenshots to help explain your problem. You can include screenshots by
copy/pasting them on GitHub or dragging-and-dropping into the GitHub page. All images are public,
so please don't post screenshots containing personal information.

[SuslikV]

Can you still open it in v2.4.4?

[cometchaserde]

Hi,

yes I can still open it in 2.4.4

[SuslikV]

Can you share a copy of the .osp file that you are unable to open with the OpenShot?

[cometchaserde]

TestOpenshot-Projekt.zip

Hope you can use it.

[SuslikV]

I didn't found issues with the project itself. Are you sure that you have issues exactly with this project (1 video clip + 1 audio clip)?

[cometchaserde]

Hi,
yes, but I did some more tests. I tried to create a new project with just a 1 video clip and 1 audio clip and Openshot 2.5 crashed while adding the files to the timeline. Then I checked the system logs and found a entry every time when Openshot crashed.
Feb 26 17:50:25 debian-t410 org.gnome.Nautilus[6334]: 140501142838144:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:185:filename(libssl_conf.so): libssl_conf.so: cannot open shared object file: No such file or directory

I did a search and found some entries and the trick described is, to do a
export OPENSSL_CONF=/etc/ssl/

When I do this within a terminal and start Openshot 2.5 from this terminal, it works.
Openshot 2.4.4 doesn't need this. It just works.

I will check what's going on with OPENSSL and it this export command solves the problem on my main computer as well. The problem with Openshot happens on my main desktop computer and on my laptop, both running Debian 10.

[cometchaserde]

Here is a link to an article related to this problem.
https://www.gitmemory.com/issue/Subsurface-divelog/subsurface/2029/487760820
or
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918727

[cometchaserde]

The described trick works also on my desktop computer with Debian 10

[ferdnyc]

Hrm. Presumably this is only an issue with the AppImage builds?

It sounds like the core issue is that they're linked/bundled with an older version of libssl, one incompatible with /etc/ssl/openssl.cnf (as described in the debian bug @cometchaserde linked to above).

That's unfortunate, because both libssl.so and libcrypto.so appear on the master list of libraries that cannot be included in AppImage bundles.

I guess our only recourse is probably going to be setting OPENSSL_CONF in the AppImage sandbox environment, for when OpenShot is run on newer Debian-based systems.

One thing struck me as odd, @cometchaserde : You said you worked around the issue by setting OPENSSL_CONF=/etc/ssl/ in your environment? The workaround presented in the Debian bug was to set OPENSSL_CONF=/dev/null — the impression I got was that /etc/ssl was the default location of the config, and it was a too-new /etc/ssl/openssl.cnf file that led to the original crash. So, I'm surprised specifying a location where that same file is found would actually work.

Regardless, would you be able to confirm that OPENSSL_DIR=/dev/null is effective (or also effective) as a workaround for this issue? If so, I think that's what we'll go with in the AppImage environment.

[ferdnyc]

@cometchaserde I had a reply from you in my email notifications, but I don't see it now. I'm guessing it was a deleted comment, should I disregard?

[cometchaserde]

Hi,
setting set OPENSSL_CONF=/dev/null does work as well.

[ferdnyc]

@cometchaserde Great, thanks! I'll leave #3283 the way it is, then.

[ferdnyc]

Fix merged. If you'd like you can try downloading the next Daily Build AppImage package (which should be ready in a few minutes) from https://openshot.org/download/ and see if that does indeed fix the problem internally.