Description of problem: Several programs that were working fine on Fedora 28 don't work any more on Fedora 29. Reason seems related to openssl-libs. Error message is: (with openssl-libs-1.1.1a-1.fc29): error:0E079065:configuration file routines:DEF_LOAD_BIO:missing equal sign:conf_def.c:362:line 39 (with openssl-libs-1.1.1-3.fc29): error:0E079065:configuration file routines:DEF_LOAD_BIO:missing equal sign:conf_def.c:362:line 40 This error seems related to the file /etc/pki/tls/openssl.cnf In lines 37-39 I have (with openssl-libs-1.1.1a-1.fc29): 37 [ crypto_policy ] 38 39 .include /etc/crypto-policies/back-ends/opensslcnf.config Example of programs with such problems: - Digikam appimage does not work: https://bugs.kde.org/show_bug.cgi?id=401377 - FoxitReader: http://forums.foxitsoftware.com/forum/portable-document-format-pdf-tools/foxit-reader/169528-foxit-reader-on-fedora-29 - https://github.com/Ultimaker/Cura/issues/4912 ("it seems to be an issue with Fedora 29 in combination with SSL") - https://pixinsight.com/forum/index.php?topic=12871.0 - https://pixinsight.com/forum/index.php?topic=12876.0 (patch proposed) Version-Release number of selected component (if applicable): openssl-libs-1.1.1a-1.fc29.x86_64
Are we talking here about third party applications that link to a different version of OpenSSL? I suppose so. Unfortunately that will not work unless they link to openssl-1.1.1 this new directive syntax of the configuration will not be working. You can delete that .include from the configuration file as a workaround, however the crypto-policies will not be fully enforced for openssl then. We could think of adding some workaround like ignoring '=' after the .include and adding it to the configuration, however it needs to be accepted upstream first.
If I understand well, the problem is that these programs use older version of openssl (e.g. included in their appimage) along with the configuration file of the system (in this case /etc/pki/tls/openssl.cnf from openssl-1.1.1) ? This is not really consistent... What should be the best to solve this ? - Appimage packagers should include openssl-1.1.1 (and not older version) ? - Openssl should ensure compatibility in their config file to cover this situation ? - (other) ?
The first option is a solution but it might not be applicable everywhere. But the question is why the images use the openssl.cnf because the compat-openssl10 on F29 and rawhide does not normally use this openssl.cnf but openssl10.cnf which should not have this issue. So either the openssl-1.0 used is different from the one from compat-openssl10 package or the apps explicitly set the config file to be openssl.cnf. Both these things are wrong. To ensure the compatibility we would have to change the .include directive syntax to be compatible with the name=value syntax and that requires upstream acceptance first.
Thank to nicolo to have done this post, and to Thomas Mraz for its explaination. At least , I understand now, from which libraries came the trouble with all the version of : PacketTracer 7.1.0, 7.1.1 and 7.2.1 (the last release currently published by CISCO). Only the old one 7.0.0 is yet running fine. Probably because it does not use external openssl-libs but an embedded one ???
Well, in fact its the reverse. I had forgotten a very important point: ==> Since the usage of packet tracer 6.3 in Fedora 20, To make this application running I had to build a package: openssl-lib-compat-1.0.0i (from Fedora 17 openssl-1.0.0i SRPM file, and a modified SPEC file to get only suitable libs in the package) , providing exactly the library with the strict version 1.0.0: /usr/lib64/libcrypto.so.1.0.0i and a symbolic link libcrypto.so.1.0.0 to this lib. Any other solution , like linking libcrypto.so.1.0.0 to /usr/lib64/libcrypto.so.1.0.2o (provided by compat-openssl10) does not work, because PacketTracer binary start by checking the TRUE version of libcrypto.so.1.0. In version PacketTracer 6.3 and 7.0, this application had no embeded libcrypto.s0.1.0.0. So the adaptation above was required. Since Then, we have today in Fedora 29 (and even in Fedora developped since september 2016) the famous compat-openssl10. But unfortunately unusable with PacketTracer-7.2, because of this difference of release: 1.0.2 provided by fedora standard Fedora compat-openssl10 package 1.0.0 checked by PacketTracer. Before rebuilding an other package, from the most update one: compat-openssl10, instead of using old openssl from Fedora17, with all its security holes , well known today, I just make an experiment: Hiding libcrypto.so.1.0.0 provided by PacketTracer package, so that this binary is forced to use the standard environment one, as shown below: ============== [root@ismf33 bin]# pwd /opt/PacketTracer-7.2.1/bin [root@ismf33 bin]# echo $PTDIR [root@ismf33 bin]# echo $LD_LIBRARY_PATH [root@ismf33 bin]# ldd PacketTracer7 ./PacketTracer7: /lib64/libcrypto.so.1.0.0: no version information available (required by ./PacketTracer7) linux-vdso.so.1 (0x00007ffccc7cb000) libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007fc7e8db8000) libQt5WebKitWidgets.so.5 => ./libQt5WebKitWidgets.so.5 (0x00007fc7e8d68000) libQt5WebKit.so.5 => ./libQt5WebKit.so.5 (0x00007fc7e6cd8000) .... ============================= In this situation, because I did not patched my openssl-lib-compat-1.0.0i package to use any other conf file than /etc/pki/tls/openssl.cnf I GOT THE ERROR described in the title of this buzilla report! If temporarily, I hide /etc/pki/tls/openssl.cnf and replace it by a symbolic link to /etc/pki/openssl10.cnf provided by standard compat-openssl10-1.0.2o-3.fc29.x86_64 ALL IS WORKING FINE
Hello, Thanks Yves for your tests. I have been able to run a program that previously crashed (in my case digikam) with appropriate LD_PRELOAD: LD_PRELOAD=/usr/lib64/libssl.so.10:/usr/lib64/libcrypto.so.10 (e.g. LD_PRELOAD=/usr/lib64/libssl.so.10:/usr/lib64/libcrypto.so.10 ./digikam.appimage) => no more crash (note: compat-openssl10-1.0.2o-3.fc29.x86_64 is well installed) Now the question: if I want to run such programs 'normally' (without LD_PRELOAD; just double-clicking on appimage), what should be done to avoid the crash ? Who is 'responsible' of the crash ? openssl team or appimage packagers ?
We now can hopefully solve it because the newest openssl (1.1.1b) allows for changing the syntax of the .include directive in the configuration file. It will take some time though. For the philosophical question "who is responsible for the crash" - I would say that appimage packagers are because they should package their bundled openssl in such way that it does not depend on system-wide configuration files, because they cannot depend on what is in them.
openssl-1.1.1b-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-84af83fe15
openssl-1.1.1b-2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-84af83fe15
openssl-1.1.1b-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
And now it breaks Ruby again :facepalm: https://bugzilla.redhat.com/show_bug.cgi?id=1610921#c3
Sorry for that, but isn't it now well in the "INI file syntax" now?