[Pkg-phototools-devel] Bug#553359: Upstream packaging

[Bernd Zeimetz]

On 07/25/2010 12:21 AM, Pascal de Bruijn wrote:
> On Sat, Jul 24, 2010 at 5:14 PM, Bernd Zeimetz <bernd at bzed.de> wrote:
>> On 07/24/2010 04:48 PM, Bernd Zeimetz wrote:
>>> Hi Pascal!
>>>
>>> On 07/24/2010 12:25 PM, Pascal de Bruijn wrote:
>>>> I think most licensing issues have been resolved upstream.
>>>
>>> I'll have a look :)
>>
>> So basically the only thing that makes my head ache is the embedded copy of libraw:
>> - it is an embedded source copy, such things are always bad, especially when it
>> comes to security issues. Also the license information for files like
>> ahd_interpolate_mod.c/ahd_partial_interpolate.c was lost as the libraw project's
>> license information is not available.
> 
> Ok, I assumed the copyright issue was about the icc files, I'll ask
> the developers to look into the .c files.
> 
> But, embedding LibRaw is quite important... Using a external copy
> entail too much practical issues:
> 
> 1. When people report raw reading bugs about Darktable 0.6 (for
> example), we have no easy way to know which LibRaw version was linked
> against.

That would be easy to work around, for example by including the version number
in some 'About' info or at similar places. For reports from Debian it is even
easier as the dependencies are printed in the report usually.

> 2. We sometimes have local patches to LibRaw, which can be quite
> important... In the past the very important Green Channel
> Equibrilation was locally patched (which took a few month's to go
> upstream to LibRaw (now in 0.10)), and now we have a Canon EOS 40D
> Rotation patch locally applied. Which is important as well, since the
> 40D is a _very_ popular camera, and we already have multiple 40D
> users.
> 
> So linking against a system LibRaw copy, will in general frustrate
> development and troubleshooting.
> 
> Please also note, others RAW converters like UFRaw also have their own
> dcraw copy embedded, they libified it themselves. So in all regards we
> are no worse or better than UFRaw in this respect.

Yeah I understand the problem very well - but on the other hand it makes it hard
for us to provide security support for such code copies. I know that dcraw is
embedded in a lot of programs and somehow I fear it will bite us badly at one
point. Until the point where we find a better solution it should be okay to keep
it in darktable, but on the long run all the upstreams which use libraw should
talk with the libraw/dcraw developers to find a proper solution.
If it really happens  that there is some security issue (imagine abitary code
execution while converting a prepared raw file, somehow I could imagine that it
might be possible to find such a hole) in there, all tools embedded dcraw/libraw
will end up with CVE numbers and have to issue security fixes. For the
distributions the situation is even worse as they have to patch a lot of tools
instead of a single library.


>> - it comes with automatically generated files without any way to recreate them
>> (guess that is in the original libraw source, but you can't assume that somebody
>> who receives the darktable source also receives the libraw source).
> 
> I'm not sure I understand... I think we have a full copy of LibRaw in
> a source tree, so this shouldn't be a problem?

No, you don't.
The libraw distribution contains files like
- COPYRIGHT
- LICENSE.*
which describes the licenses and copyright for files which do not have this
information embedded (ahd_interpolate_mod.c/ahd_partial_interpolate.c comes to
my mind).
Then we have files like internal/dcraw_fileio.cpp which were generated
automatically from dcraw.c. There should be a described way to recreate them
(actually, that is even missing in the libraw package, which is bad).

> [...]

Cheers,

Bernd



-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
                   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F