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

[Pascal de Bruijn]

On Sun, Jul 25, 2010 at 1:27 AM, Bernd Zeimetz <bernd at bzed.de> wrote:
> 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.

Yeah, it's not much fun...

>>> - 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).

Hmm my bad... We'll try to look into this before 0.6 release...

> 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).

Yeah, well we can't do anything about that, since that's an upstream
issue. Well except whining about it :)

BTW, you mentioned you were experiencing some crashes... Have you
tried latest git? Our lead developer (johannes) has been fixing all
kinds of memory leaks and and segfaults last week, so it should be
reasonably stable about now.

If you're still experiencing crashes, we'd be delighted to receive a
gdb backtrace, so we can fix it before 0.6 release.

Regards,
Pascal de Bruijn