I finally rather updated dcraw and glue to latest upstream. Committed revision 1860.
Greetings, René On Jun 10, 2013, at 9:01 , Mathieu Malaterre wrote: > On Sun, Jun 9, 2013 at 9:08 PM, Sven Eckelmann <s...@narfation.org> wrote: >> Just a small remark at the beginning: I didn't meant dcraw upstream with >> "dcraw guys" but the Debian maintainers for dcraw. And I really think it is a >> good question because the package is dead since 3 years and missing some >> updates from upstream. >> >> (Ok, the embedded copy of dcraw in exactimage seems to be older) >> >> On Sunday 09 June 2013 19:37:03 Rene Rebe wrote: >>> I think dcraw did all the original research and he does not want to make it >>> a library because he believes an executable to call is the unix way and a >>> library he could boy change so flexible. This is why I embedded the not too >>> big code to make it a simple built in library inside exact image. >> >> This is correct, but is not really about the problem here. Just to give more >> insight in what Mathieu Malaterre said: >> >> Embedded copies of code are bad when used in Distributions because (just some >> examples): >> * they increase the binary size when there would be shared object that could >> be used instead >> * they increase memory usage because different programs cannot share the >> loaded library >> * they are hard to maintain >> >> Ok, the first two points are easy to understand but the last one might be >> quite vague. So here an explanation with two different scenarios (actually it >> is the same example but with different impacts): >> >> dcraw gets a new version (lets call it 9.18 for obvious reasons) with X-Trans >> and EOS C500 support. Now all programs using an embedded copy have to be >> updated in Debian to bring these versions on par with the upstream one and >> fix >> outstanding bugs/request for EOS C500/X-Trans. This is not really trivial >> because the programs have to be identified first and then the maintainer has >> to be waken up. This is a lot of work and time spend on a task that is >> completely unnecessary. Therefore, it is better to use the library version >> when available. And yes, I am fully aware that interface changes are problems >> which can be a negative effect when switching to external libraries. >> >> Now to the part with a little more impact. Lets assume that dcraw has a bug >> which can be exploited quite easily (send a prepared image which causes some >> buffer overflows and so on). Now it is extreme important to find all versions >> of the embedded copy because otherwise it is a security risk. You don't >> really >> want to provide an web service doing raw image conversions when there might >> be >> a big security hole because the security bug was fixed in the original >> program/library but not in the embedded copy. >> >> So back to the main questions. Do you see a possible way to switch from your >> dcraw version to libraw and make more of the embedded copies optional? I >> know, >> the embedded copies from libjpeg for jpeg rotation are for example really >> hard >> because libjpeg doesn't export the necessary stuff. But it seemed to have >> caused some headaches for the previous maintainers of this package because no >> one updated the embedded copy of jpegint/transupp and it just crashed when >> used together with never versions of libjpeg like libjpeg8. And the current >> one in exactimage upstream still does. > > Very well summarized, Sven ! > > Security was mostly my main objection, since exactimage offer perl, > python and php5 bindings it is quite likely this will be used on > webserver, therefore security risk is not anymore just a theoretical > issue. > > Regards, -- ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin DE Legal: Amtsgericht Berlin (Charlottenburg) HRB 105123B, Tax-ID#: DE251602478 Managing Director: René Rebe http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de