<div dir="ltr">Hi Matthias<br><div><br>Thanks for the heads-up, we'll make OpenEXR an option soon for the kde@ ports, so that <br></div><div>we can easily get rid of it when its fate is decided.</div><div><br></div><div>mfg Tobias<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 October 2017 at 16:05, Matthias Andree <span dir="ltr"><<a href="mailto:mandree@freebsd.org" target="_blank">mandree@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings,<br>
<br>
[not yet Cc:d to ports@]<br>
<br>
I am the graphics/OpenEXR maintainer, and as some of you may already<br>
know, OpenEXR has been vulnerable for quite a while, including "execute<br>
arbitrary code" attacks.  I don't have patches I dare apply, so OpenEXR<br>
is currently marked vulnerable and I intend to tighten things up and<br>
mark FORBIDDEN soon.<br>
<br>
Tech high-level detail, I wrote, in<br>
<<a href="http://vuxml.freebsd.org/freebsd/803879e9-4195-11e7-9b08-080027ef73ec.html" rel="noreferrer" target="_blank">http://vuxml.freebsd.org/<wbr>freebsd/803879e9-4195-11e7-<wbr>9b08-080027ef73ec.html</a>>:<br>
<br>
> Brandon Perry reports:<br>
><br>
> [There] is a zip file of EXR images that cause segmentation faults in the OpenEXR library (tested against 2.2.0).<br>
><br>
> 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.<br>
> 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.<br>
> 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.<br>
> 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.<br>
> 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.<br>
> 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.<br>
> 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.<br>
<br>
The upstream has been informed [1], and there is a proposed unreviewed<br>
patch[2], but the upstream hasn't yet accepted responsibility, only<br>
responded in a non-constructive way that patch, asking for a<br>
contributors license agreement and adjourning to later "see what we can<br>
do" or something, to which the contributor of the fixes answered he's<br>
not doing any further work for lack of progress.[2]<br>
<br>
[1]: <<a href="https://github.com/openexr/openexr/issues/232" rel="noreferrer" target="_blank">https://github.com/openexr/<wbr>openexr/issues/232</a>><br>
<br>
[2]: <<a href="https://github.com/openexr/openexr/pull/233" rel="noreferrer" target="_blank">https://github.com/openexr/<wbr>openexr/pull/233</a>><br>
<br>
Bottom line, to me, OpenEXR looks abandonware and we need to prepare for<br>
getting rid of it, but I don't want to pull the rug from underneath your<br>
feet without advance warning.<br>
<br>
<br>
I have written to Ed Hanway of IL&M today to ask about the support<br>
status, and have recently committed a DEPRECATED with an EXPIRATION_TIME<br>
of EOY which I am willing to extend to 2018-03-31 for any straw or<br>
halfway reasonable cause that either of you is going to present, after<br>
which I suggest we nuke OpenEXR support in the ports tree for good, and<br>
I intend to mark the port FORBIDDEN soon enough.<br>
<br>
<br>
How should we proceed?<br>
<br>
- are all of your ports good without OpenEXR, and support, for instance,<br>
16-bit TIFF?<br>
<br>
- are there OpenEXR alternatives that your ports could use and that we<br>
could move<br>
<br>
- is either of your ports dependent on OpenEXR to be useful?<br>
<br>
- is anyone aware of another vendor auditing patches or actively<br>
distributing patches for OpenEXR, or a patched version, that they are<br>
supporting, and that we could rely on?<br>
I am loathe to use unaudited third party patches.<br>
<br>
This is a list generated from <a href="http://freshports.org/graphics/OpenEXR" rel="noreferrer" target="_blank">http://freshports.org/<wbr>graphics/OpenEXR</a>,<br>
sorted by maintainer - to me this appears to be the list of<br>
maintainer/port_origin pairs of ports that require OpenEXR by default.<br>
<br>
Thanks for your time.<br>
<br>
Regards,<br>
Matthias<br>
<br>
> FreeBSD@Shaneware.biz: graphics/blender<br>
> FreeBSD@Shaneware.biz: graphics/openimageio<br>
> FreeBSD@Shaneware.biz: graphics/openshadinglanguage<br>
> FreeBSD@Shaneware.biz: graphics/py-openimageio<br>
> amdmi3@FreeBSD.org: graphics/nvidia-texture-tools<br>
> danfe@FreeBSD.org: graphics/appleseed<br>
> danfe@FreeBSD.org: graphics/hdr_tools<br>
> danfe@FreeBSD.org: graphics/mitsuba<br>
> danilo@FreeBSD.org: graphics/vips<br>
> dumbbell@FreeBSD.org: graphics/darktable<br>
> ehaupt@FreeBSD.org: graphics/exrtools<br>
> gnome@FreeBSD.org: graphics/gegl<br>
> gnome@FreeBSD.org: graphics/gegl3<br>
> grog@FreeBSD.org: graphics/enblend<br>
> grog@FreeBSD.org: graphics/hugin<br>
> <a href="mailto:h2%2Bfbsdports@fsfe.org">h2+fbsdports@fsfe.org</a>: graphics/luminance<br>
> <a href="mailto:h2%2Bfbsdports@fsfe.org">h2+fbsdports@fsfe.org</a>: graphics/luminance-qt5<br>
> <a href="mailto:jamesb-bsd@excamera.com">jamesb-bsd@excamera.com</a>: graphics/py-openexr<br>
> kde@FreeBSD.org: editors/calligra<br>
> kde@FreeBSD.org: graphics/kf5-kimageformats<br>
> kde@FreeBSD.org: graphics/krita<br>
> kde@FreeBSD.org: x11/kde4-runtime<br>
> kde@FreeBSD.org: x11/kdelibs4<br>
> multimedia@FreeBSD.org: graphics/gstreamer1-plugins-<wbr>openexr<br>
> ports@FreeBSD.org: graphics/ampasCTL<br>
> ports@FreeBSD.org: graphics/aqsis<br>
> ports@FreeBSD.org: graphics/cinepaint<br>
> ports@FreeBSD.org: graphics/exact-image<br>
> ports@FreeBSD.org: graphics/fyre<br>
> ports@FreeBSD.org: graphics/pixie<br>
> ports@FreeBSD.org: graphics/simpleviewer<br>
> ports@FreeBSD.org: graphics/vigra<br>
> ports@FreeBSD.org: science/gwyddion<br>
> rm@FreeBSD.org: graphics/gimp-gmic-plugin<br>
> thierry@FreeBSD.org: graphics/cimg<br>
> woodsb02@FreeBSD.org: devel/synfig<br>
<br>
</blockquote></div><br></div>