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
