All the CVEs you listed (and all that I know about) are fixed by OIIO 2.4.6 (some earlier, such as 2.4.5). I just double checked the ones you cited to confirm.
TALOS 1631 and 1636 were fixed in 2.4.5 but inadvertently left out of the release notes. The release notes will be retroactively fixed for the 2.4.7 release on Jan 1. As for OIIO 2.1 (released in 2019 and last updated in fall 2020) and 1.5 (!! released in Jan 2015 and last updated in Mar 2016)... I'm not sure what to tell you. I don't even have an especially easy way to build those versions to verify that the CVE bugs are present (since probably dozens of patches would need to get backported just to allow them to build with the compilers and libraries installed on any of my systems now), and the fixes to those bugs present in later releases may not be able to backport cleanly. I just don't have the resources to keep such old releases buildable and to backport fixes. This is not unique to OIIO. The other libraries in our ecosystem (such as OpenEXR, as a familiar example) are just barely able to backport the most critical fixes to the releases from 2020 (under duress, and needing substantial debate over whether to bother), and certainly would not even entertain the debate about whether to rerelease the versions from 2015. I recognize the spot this puts you in as a distro maintainer with LTS releases. I just don't have a good solution. We don't have the resources to maintain more than the current and immediately prior major releases, and we also acknowledge that "it's fixed in recent releases, so upgrade" is a non-starter for you because (due to what we thought was a benign use of namespacing) we routinely break the entire ABI at yearly major releases. FWIW, all of these projects are giving thought to how to address this better in the future. What we'd like to do is make it so that the ABIs almost never break in a non-back-compatible way, so that we can have fairly long stretches of major releases that are upgradeable in the field. Maybe clever use of symbol versioning in the libraries? I think a number of the projects are investigating a sustainable approach, but traditional LTS of supporting a several-years-old release with backports is just not feasible for any but the most well-funded and staffed open source projects. > On Dec 24, 2022, at 5:19 AM, Richard Shaw <hobbes1...@gmail.com> wrote: > > I've built the last 2.3 and 2.4 releases that address most of them, but I ran > into a situation where the CVE's listed in the release notes didn't match > what Redhat put in Bugzilla for Fedora and EPEL. And I have a couple with a > TALOS number that I can't find in the release notes so I'm not sure if > they've been addressed. > > https://bugzilla.redhat.com/show_bug.cgi?id=2156031 > <https://bugzilla.redhat.com/show_bug.cgi?id=2156031> > https://bugzilla.redhat.com/show_bug.cgi?id=2156024 > <https://bugzilla.redhat.com/show_bug.cgi?id=2156024> > https://bugzilla.redhat.com/show_bug.cgi?id=2156021 > <https://bugzilla.redhat.com/show_bug.cgi?id=2156021> > https://bugzilla.redhat.com/show_bug.cgi?id=2156016 > <https://bugzilla.redhat.com/show_bug.cgi?id=2156016> > > There are matching bugs for EPEL but I'm not sure what I'm going to do about > that yet. EPEL 9 is on 2.4 so no issues updating that one but EPEL 8 is on > 2.1 and EPEL 7 is on 1.5... > > Thanks, > Richard > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz l...@larrygritz.com
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
