Hello all.
Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with libcrypto.so.1.1 and fails:
+ /usr/bin/cmake -S . -B redhat-linux-build -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release RPM build errors: /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Child return code was: 1
Affected Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927
Hi,
Vitaly Zaitsev via devel devel@lists.fedoraproject.org writes:
/usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
As a workaround, can you try a BuildRequires of `openssl1.1`? That should get the libraries and let cmake proceed.
My scratch build with the added BuildRequires:
https://koji.fedoraproject.org/koji/taskinfo?taskID=79546890
Thanks, Omair
-- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
On 03/12/2021 15:05, Omair Majid wrote:
As a workaround, can you try a BuildRequires of `openssl1.1`? That should get the libraries and let cmake proceed.
This is a dirty hack. You package can be linked with legacy openssl1.1 and introduce another compatibility issues.
On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:
Hello all.
Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with libcrypto.so.1.1 and fails:
- /usr/bin/cmake -S . -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release RPM build errors: /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Child return code was: 1
Affected Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927
Same issue with my build of cswrap. It is weird that it happens on x86_64 only:
https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725
Kamil
On 03. 12. 21 15:45, Kamil Dudka wrote:
On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:
Hello all.
Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with libcrypto.so.1.1 and fails:
- /usr/bin/cmake -S . -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release RPM build errors: /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Child return code was: 1
Affected Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927
Same issue with my build of cswrap. It is weird that it happens on x86_64 only:
https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725
This has surfaced by the last package in the default buildroot dropping the dependency on openssl1.1:
https://bugzilla.redhat.com/show_bug.cgi?id=2022026#c7
I see more apps affected:
<mock-chroot> sh-5.1$ cmake --help cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
<mock-chroot> sh-5.1$ appstream-util --help appstream-util: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
It seems that something still pulls in openssl1.1 on other architectures, e.g. in this build:
https://koschei.fedoraproject.org/build/11634367
Both aarch64 and ppc64le have openssl1.1 in the root.log
On 03. 12. 21 15:49, Miro Hrončok wrote:
On 03. 12. 21 15:45, Kamil Dudka wrote:
On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:
Hello all.
Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with libcrypto.so.1.1 and fails:
- /usr/bin/cmake -S . -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release RPM build errors: /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Child return code was: 1
Affected Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927
Same issue with my build of cswrap. It is weird that it happens on x86_64 only:
https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725
This has surfaced by the last package in the default buildroot dropping the dependency on openssl1.1:
https://bugzilla.redhat.com/show_bug.cgi?id=2022026#c7
I see more apps affected:
<mock-chroot> sh-5.1$ cmake --help cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
<mock-chroot> sh-5.1$ appstream-util --help appstream-util: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
It seems that something still pulls in openssl1.1 on other architectures, e.g. in this build:
https://koschei.fedoraproject.org/build/11634367
Both aarch64 and ppc64le have openssl1.1 in the root.log
It seems that libarchive still requires libcrypto.so.1.1()(64bit)
But on x86_64, opae-devel provides that with:
ExclusiveArch: x86_64
I'll report that.
On 03. 12. 21 15:59, Miro Hrončok wrote:
On 03. 12. 21 15:49, Miro Hrončok wrote:
On 03. 12. 21 15:45, Kamil Dudka wrote:
On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:
Hello all.
Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with libcrypto.so.1.1 and fails:
- /usr/bin/cmake -S . -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release RPM build errors: /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Child return code was: 1
Affected Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927
Same issue with my build of cswrap. It is weird that it happens on x86_64 only:
https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725
This has surfaced by the last package in the default buildroot dropping the dependency on openssl1.1:
https://bugzilla.redhat.com/show_bug.cgi?id=2022026#c7
I see more apps affected:
<mock-chroot> sh-5.1$ cmake --help cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
<mock-chroot> sh-5.1$ appstream-util --help appstream-util: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
It seems that something still pulls in openssl1.1 on other architectures, e.g. in this build:
https://koschei.fedoraproject.org/build/11634367
Both aarch64 and ppc64le have openssl1.1 in the root.log
It seems that libarchive still requires libcrypto.so.1.1()(64bit)
But on x86_64, opae-devel provides that with:
ExclusiveArch: x86_64
I'll report that.
https://bugzilla.redhat.com/show_bug.cgi?id=2028852
On 03. 12. 21 16:06, Miro Hrončok wrote:
On 03. 12. 21 15:59, Miro Hrončok wrote:
On 03. 12. 21 15:49, Miro Hrončok wrote:
On 03. 12. 21 15:45, Kamil Dudka wrote:
On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:
Hello all.
Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with libcrypto.so.1.1 and fails:
- /usr/bin/cmake -S . -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release RPM build errors: /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Child return code was: 1
Affected Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927
Same issue with my build of cswrap. It is weird that it happens on x86_64 only:
https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725
This has surfaced by the last package in the default buildroot dropping the dependency on openssl1.1:
https://bugzilla.redhat.com/show_bug.cgi?id=2022026#c7
I see more apps affected:
<mock-chroot> sh-5.1$ cmake --help cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
<mock-chroot> sh-5.1$ appstream-util --help appstream-util: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
It seems that something still pulls in openssl1.1 on other architectures, e.g. in this build:
https://koschei.fedoraproject.org/build/11634367
Both aarch64 and ppc64le have openssl1.1 in the root.log
It seems that libarchive still requires libcrypto.so.1.1()(64bit)
But on x86_64, opae-devel provides that with:
ExclusiveArch: x86_64
I'll report that.
The problem is now fixed. The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more.
On 03/12/2021 17:41, Miro Hrončok wrote:
The problem is now fixed.
I can confirm. Many thanks.
The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more.
I think FESCo should create a strict policy on bundling cryptographic libraries.
On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote:
On 03/12/2021 17:41, Miro Hrončok wrote:
The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more.
I think FESCo should create a strict policy on bundling cryptographic libraries.
Well bundling a binary from upstream is already against policy so I don't see how that helps.
The problem isn't a lack of policy, it's that the packager didn't notice those files or didn't realise they weren't allowed.
Tom
On 03/12/2021 18:25, Tom Hughes wrote:
Well bundling a binary from upstream is already against policy so I don't see how that helps.
Yes, no pre-built binaries are allowed.
The problem isn't a lack of policy, it's that the packager didn't notice those files or didn't realise they weren't allowed.
I mean, FESCo should prohibit bundling of any cryptographic libraries because these libraries are the main source of critical vulnerabilities.
On Fri, 2021-12-03 at 17:25 +0000, Tom Hughes via devel wrote:
On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote:
On 03/12/2021 17:41, Miro Hrončok wrote:
The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more.
I think FESCo should create a strict policy on bundling cryptographic libraries.
Well bundling a binary from upstream is already against policy so I don't see how that helps.
The problem isn't a lack of policy, it's that the packager didn't notice those files or didn't realise they weren't allowed.
So the opae-2.0.0 tarball has libcrypto embedded-in what is the process now ?
This stuff is used for a Python tool that is used to sign some binary, almost certainly there is absolutely no reason to bundle libcrypto, the tool should probably be unbundled and turned into a regular python module opae depends on.
Do we know who is the current maintainer? The changelog seem to imply Intel dropped it into Fedora and never maintained it after Sep 17 2020 ...
Simo.
Tom
-- Tom Hughes (tom@compton.nu) http://compton.nu/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 03/12/2021 17:48, Simo Sorce wrote:
On Fri, 2021-12-03 at 17:25 +0000, Tom Hughes via devel wrote:
On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote:
On 03/12/2021 17:41, Miro Hrončok wrote:
The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more.
I think FESCo should create a strict policy on bundling cryptographic libraries.
Well bundling a binary from upstream is already against policy so I don't see how that helps.
The problem isn't a lack of policy, it's that the packager didn't notice those files or didn't realise they weren't allowed.
So the opae-2.0.0 tarball has libcrypto embedded-in what is the process now ?
This stuff is used for a Python tool that is used to sign some binary, almost certainly there is absolutely no reason to bundle libcrypto, the tool should probably be unbundled and turned into a regular python module opae depends on.
It has an openssl.py that dlopen's the so:
def _find_openssl_so(self, version, *paths):
candidates = list(paths)
crypto = util.find_library('crypto') if crypto:
candidates.insert(0, crypto)
for c in candidates:
dll = CDLL(c)
So that might already find the system one if you have it but probably only if you have openssl-devel installed to get the .so link with no version.
But dropping the binaries and doing a relatively minor patch to that is likely all that is needed.
Do we know who is the current maintainer? The changelog seem to imply Intel dropped it into Fedora and never maintained it after Sep 17 2020 ...
Well src.fpo says trix aka Tom Rix is the maintainer.
Tom
Dne 03. 12. 21 v 19:07 Tom Hughes via devel napsal(a):
On 03/12/2021 17:48, Simo Sorce wrote:
On Fri, 2021-12-03 at 17:25 +0000, Tom Hughes via devel wrote:
On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote:
On 03/12/2021 17:41, Miro Hrončok wrote:
The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more.
I think FESCo should create a strict policy on bundling cryptographic libraries.
Well bundling a binary from upstream is already against policy so I don't see how that helps.
The problem isn't a lack of policy, it's that the packager didn't notice those files or didn't realise they weren't allowed.
So the opae-2.0.0 tarball has libcrypto embedded-in what is the process now ?
This stuff is used for a Python tool that is used to sign some binary, almost certainly there is absolutely no reason to bundle libcrypto, the tool should probably be unbundled and turned into a regular python module opae depends on.
It has an openssl.py that dlopen's the so:
def _find_openssl_so(self, version, *paths):
candidates = list(paths)
crypto = util.find_library('crypto') if crypto:
candidates.insert(0, crypto)
for c in candidates:
dll = CDLL(c)
So that might already find the system one if you have it but probably only if you have openssl-devel installed to get the .so link with no version.
But dropping the binaries and doing a relatively minor patch to that is likely all that is needed.
Or just symlink ...
Vít
Do we know who is the current maintainer? The changelog seem to imply Intel dropped it into Fedora and never maintained it after Sep 17 2020 ...
Well src.fpo says trix aka Tom Rix is the maintainer.
Tom
On 03. 12. 21 18:48, Simo Sorce wrote:
Do we know who is the current maintainer? The changelog seem to imply Intel dropped it into Fedora and never maintained it after Sep 17 2020 ...
Tom Rix from Red Hat. Username trix.
On Fri, Dec 03, 2021 at 05:41:31PM +0100, Miro Hrončok wrote:
On 03. 12. 21 16:06, Miro Hrončok wrote:
On 03. 12. 21 15:59, Miro Hrončok wrote:
On 03. 12. 21 15:49, Miro Hrončok wrote:
On 03. 12. 21 15:45, Kamil Dudka wrote:
On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:
It seems that libarchive still requires libcrypto.so.1.1()(64bit)
But on x86_64, opae-devel provides that with:
ExclusiveArch: x86_64
I'll report that.
The problem is now fixed. The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more.
Bundling pre-built openssl is a serious problem, because Fedora is required to strip various functionality from openssl at the source level. We cannot ship these binaries in the RPM, nor can we even have them in the source tarball AFAIK.
IOW, stripping the dependancies from the RPM here is not sufficient. IIUC, the tarball needs to be unpacked, the openssl binaries removed, and a new tarball created for import into Fedora dist-git lookside archive storage.
Regards, Daniel
On 03. 12. 21 18:41, Daniel P. Berrangé wrote:
On Fri, Dec 03, 2021 at 05:41:31PM +0100, Miro Hrončok wrote:
On 03. 12. 21 16:06, Miro Hrončok wrote:
On 03. 12. 21 15:59, Miro Hrončok wrote:
On 03. 12. 21 15:49, Miro Hrončok wrote:
On 03. 12. 21 15:45, Kamil Dudka wrote:
On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:
It seems that libarchive still requires libcrypto.so.1.1()(64bit)
But on x86_64, opae-devel provides that with:
ExclusiveArch: x86_64
I'll report that.
The problem is now fixed. The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more.
Bundling pre-built openssl is a serious problem, because Fedora is required to strip various functionality from openssl at the source level. We cannot ship these binaries in the RPM, nor can we even have them in the source tarball AFAIK.
IOW, stripping the dependancies from the RPM here is not sufficient. IIUC, the tarball needs to be unpacked, the openssl binaries removed, and a new tarball created for import into Fedora dist-git lookside archive storage.
I agree. I applied the smallest possible bandaid to unblock other packagers, but the original cause of this problem remains to be solved by the package maintainers. Thta is why https://bugzilla.redhat.com/2028852 remains open.
-
Daniel P. Berrangé -
Kamil Dudka -
Miro Hrončok -
Omair Majid -
Simo Sorce -
Tom Hughes -
Vitaly Zaitsev -
Vít Ondruch