2020.08.16 15:59 "Re: [Tiff] Disable Old JPEG in libtiff by default!", by Roger Leigh

Without opining one way or the other on this, I am wondering if there exists a corpus of test data for "old jpeg" that a maintainer could refer to. That would seem to be a prerequisite for practical > maintenance.

You are correct that there does not appear to be a corpus of test data for "old jpeg" or a libtiff test suite which would use it to verify that the software works correctly.

More significantly, there does not appear to be a dedicated volunteer to maintain OJPEG support in libtiff.

If there is not enough interest in the community to maintain the feature properly, it seems like it should be disabled by default.

Hi Bob,

I certainly think that there would be value in having a corpus of test data which integration tests can be run against, and which can be expanded to ensure that it behaves correctly in corner cases and if security issues are spotted. If we don't have such data for "old jpeg", then I think it would be useful to acquire some irrespective of whether the option is on or off by default.

Is there any thought on how such removal/optional feature support should be done, e.g.

adding an additional open mode flag e.g. "j" (i.e. having it always compiled in, but off by default unless explicitly asked for)
making it a configure-time option (i.e. having it off by default, but on by default if compiled in)
outright removal from the source tree (use an older release for this functionality if reading old images is required)

The first two options could also be combined, so you could choose the runtime default, and a compile-time setting as well. But that might be getting overly complex.

With regard to where to store test data, we could create a separate project under the "libtiff" group, e.g. "tiff-samples". GitLab supports Git-LFS for large file storage, so we would be able to version control large image datasets separately from the main codebase. These could be added to the CI test steps.

Kind regards,

Roger