7:58 a.m.
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
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:05 a.m.
Hi,
Vitaly Zaitsev via devel <devel(a)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
8:35 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:45 a.m.
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
8:49 a.m.
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
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
8:59 a.m.
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:06 a.m.
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
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:41 a.m.
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.
https://bugzilla.redhat.com/show_bug.cgi?id=2028852
The problem is now fixed. The bundled openssl in opae worries me still, but
that's not causing issues in dependency resolution any more.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
11:16 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
11:25 a.m.
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
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
11:33 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
11:48 a.m.
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(a)compton.nu)
http://compton.nu/
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
12:07 p.m.
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
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
5:15 a.m.
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
11:41 a.m.
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.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2028852
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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
3:08 p.m.
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.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=2028852
>
> 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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
879
days inactive
882
days old
16 comments
8 participants
participants (8)
-
Daniel P. Berrangé -
Kamil Dudka -
Miro Hrončok -
Omair Majid -
Simo Sorce -
Tom Hughes -
Vitaly Zaitsev -
Vít Ondruch