Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#711774: exactimage: dcraw vs libraw ?
2 views
Skip to first unread message
Mathieu Malaterre
Jun 9, 2013, 12:30:01 PM6/9/13
to
Package: exactimage
Severity: normal
exactimage uses convenient copy of dcraw, instead of relying on libs (eg. libraw). Could that be changed ?
See: §4.13 Convenience copies of code
http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
-- System Information:
Debian Release: 6.0.7
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable'), (200, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Severity: normal
exactimage uses convenient copy of dcraw, instead of relying on libs (eg. libraw). Could that be changed ?
See: §4.13 Convenience copies of code
http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
-- System Information:
Debian Release: 6.0.7
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable'), (200, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sven Eckelmann
Jun 9, 2013, 1:00:02 PM6/9/13
to
forwarded 711774 exact...@exactcode.de
thanks
On Sun, Jun 09, 2013 at 06:18:04PM +0200, Mathieu Malaterre wrote:
> exactimage uses convenient copy of dcraw, instead of relying on libs (eg. libraw). Could that be changed ?
I haven't checked it in detail but libraw is not the same as the included
modified version of dcraw [1]. I will not start to cripple exactimage in Debian
by ripping out this part of the code but I will try to get in contact with
upstream to find a way in getting a possible migration path to libraw to avoid
too many differences between upstream and Debian version.
> See: §4.13 Convenience copies ofcode
> http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
Btw. did anyone actually try to tell the dcraw guys to switch to libraw?
Kind regards,
Sven
[1] http://rene.rebe.de/2008-11-04/exactimage-065-updates-still-camera-raw-support/
thanks
On Sun, Jun 09, 2013 at 06:18:04PM +0200, Mathieu Malaterre wrote:
> exactimage uses convenient copy of dcraw, instead of relying on libs (eg. libraw). Could that be changed ?
modified version of dcraw [1]. I will not start to cripple exactimage in Debian
by ripping out this part of the code but I will try to get in contact with
upstream to find a way in getting a possible migration path to libraw to avoid
too many differences between upstream and Debian version.
> See: §4.13 Convenience copies ofcode
> http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
Btw. did anyone actually try to tell the dcraw guys to switch to libraw?
Kind regards,
Sven
[1] http://rene.rebe.de/2008-11-04/exactimage-065-updates-still-camera-raw-support/
Rene Rebe
Jun 9, 2013, 2:10:02 PM6/9/13
to
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.
Sent on the go - http://ExactCODE.com Germany.
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> li...@exactcode.de with a subject of: unsubscribe exact-image
Sent on the go - http://ExactCODE.com Germany.
> If you wish to unsubscribe from this mailing, send mail to
> li...@exactcode.de with a subject of: unsubscribe exact-image
Sven Eckelmann
Jun 9, 2013, 3:20:02 PM6/9/13
to
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.
Kind regards,
Sven
"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.
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.
Kind regards,
Sven
Mathieu Malaterre
Jun 10, 2013, 3:10:01 AM6/10/13
to
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,
René Rebe
Jun 10, 2013, 6:10:01 AM6/10/13
to
Hi,
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é Rebe
Aug 9, 2013, 7:30:01 AM8/9/13
to
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:
--
ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin
DE Legal: Amtsgericht Berlin (Charlottenburg) HRB 105123B, Tax-ID#: DE251602478
Managing Director: René Rebe
ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin
DE Legal: Amtsgericht Berlin (Charlottenburg) HRB 105123B, Tax-ID#: DE251602478
Managing Director: René Rebe
Sven Eckelmann
Aug 27, 2019, 12:10:03 PM8/27/19
to
On Thursday, 4 June 2015 17:41:01 CEST you wrote:
> I can drop the dcraw support in exactimage. But I want to avoid shipping
> libraw patches which are not accepted by upstream and then give me even more
> problems with René.
The different view on libraw vs. dcraw couldn't be solved with upstream (yet).
I will close this ticket for now but in case someone wants to spend time on
it, the package is currently marked as RFA (because I don't use it anymore
myself).
Thanks,
Sven
> I can drop the dcraw support in exactimage. But I want to avoid shipping
> libraw patches which are not accepted by upstream and then give me even more
> problems with René.
The different view on libraw vs. dcraw couldn't be solved with upstream (yet).
I will close this ticket for now but in case someone wants to spend time on
it, the package is currently marked as RFA (because I don't use it anymore
myself).
Thanks,
Sven
0 new messages