Hi,
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.
Well, the dcraw author is the authority when it come to RAN reverse
engineering. I would rather use his, than some other random library. That it is
not a real library, and the ongoing compatibility breakage of libpng and
libjpeg is very unfortunate, but honestly not my construction site. After all
my decade of excessive open source work and contribution I'm left vastly
disappointment by all this movements, incompatibly, breakage and flamewars. In
the end all the big companies like Google, Facebook, IBM, Oracle and others
just make the big money of all our work there. I'm afraid I can not longer
donate my short life to their profit and thus mostly do other stuff now, like
for Mac and even Windows.
I adapt ExactImage to new library versions as time allows, but unfortunately
the random breakage and incompatibility mess does not motivate me too much to
look into things like that.
Patches welcome.
René
--
http://exactcode.com | http://exactscan.com | http://ocrkit.com |
http://t2-project.org | http://rene.rebe.de
