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, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
