yafaray-3.5.1-r1.ebuild: openexr? ( <media-libs/openexr-3.0.0:0= ) Cleanup necessary for security issues, but can't with this dependency.
There might be some confusion, as to what version comparison here means. Earlier we had OpenEXR slotted, <v3 were slot 0 and >=v3 were slot 3. Upstream maintains two series of branches, the RB-2.5 branch with the old IlmBase/OpenEXR code base and the RB-3.x branches with the new OpenEXR codebase which depends on Imath. As far as I have noticed, all security issues have been backported to the RB-2.5 branch by upstream, where applicable, and should be solved for openexr-2.5.8 as well. The b.g.o. security issues for <3.x.y all refer to the RB-3.x branch of OpenEXR, thus <media-libs/openexr-3.1.5 in bug #838079 for examples means openexr-3.0.0 <= ver < openexr-3.1.5, similar for the other openexr security related issues. That said, I'm working on cleaning up the IlmBase / OpenEXR-2 packages, yet there are still a few packages which depend in IlmBase or OpenEXR-2. See for example https://github.com/ampas/CTL/issues/100
Have you confirmed that each of the security issues in the dependent bugs have backports for 2.5.x?
I did my best to verify, that the dependent bugs are not available in 2.5 or have been backported.
Another point. There are quite a few packages, which don't have yet a dependency string clearly stating whether they depend on <v3 or on >=v3. I suspect, quite a few of them will either fail to build properly or silently disable their support and won't work with OpenEXR-3. I'm quite sure, that any version <openvdb-8.2.0 should fail to build against openexr-3, although their depstring uses no version specifier. I asked if I can remove them to prepare for removal of OpenEXR-2.5 some time ago in IRC, but got no response. There might be other packages, using an insufficient depstring.
(In reply to Bernd from comment #4) > Another point. There are quite a few packages, which don't have yet a > dependency string clearly stating whether they depend on <v3 or on >=v3. I > suspect, quite a few of them will either fail to build properly or silently > disable their support and won't work with OpenEXR-3. If there are more packages that fail to build with OpenEXR 3 that don't have bugs filed and dependencies reflecting that, then bugs should be filed and dependencies fixed. > I'm quite sure, that any version <openvdb-8.2.0 should fail to build against > openexr-3, although their depstring uses no version specifier. I asked if I > can remove them to prepare for removal of OpenEXR-2.5 some time ago in IRC, > but got no response. There might be other packages, using an insufficient > depstring. Sam agreed with you, but it looks like he said that after you had quit. So, please do.
(In reply to Bernd from comment #3) > I did my best to verify, that the dependent bugs are not available in 2.5 or > have been backported. Given how hard it is to verify, I think we should be cautious and treat the 2.x versions as vulnerable, even if it's a bit of a pain.
(In reply to John Helmert III from comment #6) > (In reply to Bernd from comment #3) > > I did my best to verify, that the dependent bugs are not available in 2.5 or > > have been backported. > > Given how hard it is to verify, I think we should be cautious and treat the > 2.x versions as vulnerable, even if it's a bit of a pain. Actually, now that I see your comments in the security bugs, these are being tracked much better than I remember, so I'll trust you there. But, that means we won't be able to properly GLSA given the issues with targeting multiple branches.
(In reply to John Helmert III from comment #5) > If there are more packages that fail to build with OpenEXR 3 that don't have > bugs filed and dependencies reflecting that, then bugs should be filed and > dependencies fixed. > I'm currently testing all revdeps of openexr and file bugs for each one I find. > Sam agreed with you, but it looks like he said that after you had quit. So, > please do. IIRC I staid for several hours, but anyway, once I verified this assumption, I go and prepare a PR for removal of the affected versions.
(In reply to John Helmert III from comment #6) > (In reply to Bernd from comment #3) > > I did my best to verify, that the dependent bugs are not available in 2.5 or > > have been backported. > > Given how hard it is to verify, I think we should be cautious and treat the > 2.x versions as vulnerable, even if it's a bit of a pain. I would like to work towards removal of the 2.5 version and last riting of ilmbase. Might still take some more time to get to this point though.
Thank you for your work!
I checked all the revdeps and filed bugs for it, all blocking #722500 and the 3 security related blocks you have listed as well for this issue.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2c321cfa45359da3863c842de6d1b926645b65fd commit 2c321cfa45359da3863c842de6d1b926645b65fd Author: Bernd Waibel <waebbl-gentoo@posteo.net> AuthorDate: 2022-10-25 12:16:43 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-30 09:41:02 +0000 media-gfx/yafaray: disable OpenEXR support The package currently only supports <openexr-3. Until upstream has updated to support OpenEXR 3, we disable support for this file format. Bump to EAPI 8, support Python 3.11 Closes: https://bugs.gentoo.org/877865 Signed-off-by: Bernd Waibel <waebbl-gentoo@posteo.net> Closes: https://github.com/gentoo/gentoo/pull/27942 Signed-off-by: Sam James <sam@gentoo.org> .../{yafaray-3.5.1-r1.ebuild => yafaray-3.5.1-r2.ebuild} | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)
