Hi Matthias Thanks for the heads-up, we'll make OpenEXR an option soon for the kde@ ports, so that we can easily get rid of it when its fate is decided.
mfg Tobias On 22 October 2017 at 16:05, Matthias Andree <[email protected]> wrote: > Greetings, > > [not yet Cc:d to ports@] > > I am the graphics/OpenEXR maintainer, and as some of you may already > know, OpenEXR has been vulnerable for quite a while, including "execute > arbitrary code" attacks. I don't have patches I dare apply, so OpenEXR > is currently marked vulnerable and I intend to tighten things up and > mark FORBIDDEN soon. > > Tech high-level detail, I wrote, in > <http://vuxml.freebsd.org/freebsd/803879e9-4195-11e7- > 9b08-080027ef73ec.html>: > > > Brandon Perry reports: > > > > [There] is a zip file of EXR images that cause segmentation faults in > the OpenEXR library (tested against 2.2.0). > > > > CVE-2017-9110 In OpenEXR 2.2.0, an invalid read of size 2 in the > hufDecode function in ImfHuf.cpp could cause the application to crash. > > CVE-2017-9111 In OpenEXR 2.2.0, an invalid write of size 8 in the > storeSSE function in ImfOptimizedPixelReading.h could cause the application > to crash or execute arbitrary code. > > CVE-2017-9112 In OpenEXR 2.2.0, an invalid read of size 1 in the getBits > function in ImfHuf.cpp could cause the application to crash. > > CVE-2017-9113 In OpenEXR 2.2.0, an invalid write of size 1 in the > bufferedReadPixels function in ImfInputFile.cpp could cause the application > to crash or execute arbitrary code. > > CVE-2017-9114 In OpenEXR 2.2.0, an invalid read of size 1 in the refill > function in ImfFastHuf.cpp could cause the application to crash. > > CVE-2017-9115 In OpenEXR 2.2.0, an invalid write of size 2 in the = > operator function in half.h could cause the application to crash or execute > arbitrary code. > > CVE-2017-9116 In OpenEXR 2.2.0, an invalid read of size 1 in the > uncompress function in ImfZip.cpp could cause the application to crash. > > The upstream has been informed [1], and there is a proposed unreviewed > patch[2], but the upstream hasn't yet accepted responsibility, only > responded in a non-constructive way that patch, asking for a > contributors license agreement and adjourning to later "see what we can > do" or something, to which the contributor of the fixes answered he's > not doing any further work for lack of progress.[2] > > [1]: <https://github.com/openexr/openexr/issues/232> > > [2]: <https://github.com/openexr/openexr/pull/233> > > Bottom line, to me, OpenEXR looks abandonware and we need to prepare for > getting rid of it, but I don't want to pull the rug from underneath your > feet without advance warning. > > > I have written to Ed Hanway of IL&M today to ask about the support > status, and have recently committed a DEPRECATED with an EXPIRATION_TIME > of EOY which I am willing to extend to 2018-03-31 for any straw or > halfway reasonable cause that either of you is going to present, after > which I suggest we nuke OpenEXR support in the ports tree for good, and > I intend to mark the port FORBIDDEN soon enough. > > > How should we proceed? > > - are all of your ports good without OpenEXR, and support, for instance, > 16-bit TIFF? > > - are there OpenEXR alternatives that your ports could use and that we > could move > > - is either of your ports dependent on OpenEXR to be useful? > > - is anyone aware of another vendor auditing patches or actively > distributing patches for OpenEXR, or a patched version, that they are > supporting, and that we could rely on? > I am loathe to use unaudited third party patches. > > This is a list generated from http://freshports.org/graphics/OpenEXR, > sorted by maintainer - to me this appears to be the list of > maintainer/port_origin pairs of ports that require OpenEXR by default. > > Thanks for your time. > > Regards, > Matthias > > > [email protected]: graphics/blender > > [email protected]: graphics/openimageio > > [email protected]: graphics/openshadinglanguage > > [email protected]: graphics/py-openimageio > > [email protected]: graphics/nvidia-texture-tools > > [email protected]: graphics/appleseed > > [email protected]: graphics/hdr_tools > > [email protected]: graphics/mitsuba > > [email protected]: graphics/vips > > [email protected]: graphics/darktable > > [email protected]: graphics/exrtools > > [email protected]: graphics/gegl > > [email protected]: graphics/gegl3 > > [email protected]: graphics/enblend > > [email protected]: graphics/hugin > > [email protected]: graphics/luminance > > [email protected]: graphics/luminance-qt5 > > [email protected]: graphics/py-openexr > > [email protected]: editors/calligra > > [email protected]: graphics/kf5-kimageformats > > [email protected]: graphics/krita > > [email protected]: x11/kde4-runtime > > [email protected]: x11/kdelibs4 > > [email protected]: graphics/gstreamer1-plugins-openexr > > [email protected]: graphics/ampasCTL > > [email protected]: graphics/aqsis > > [email protected]: graphics/cinepaint > > [email protected]: graphics/exact-image > > [email protected]: graphics/fyre > > [email protected]: graphics/pixie > > [email protected]: graphics/simpleviewer > > [email protected]: graphics/vigra > > [email protected]: science/gwyddion > > [email protected]: graphics/gimp-gmic-plugin > > [email protected]: graphics/cimg > > [email protected]: devel/synfig > >
