2024.02.05 04:00 "Re: [Tiff] www.libtiff.org is restored", by William Bader

Unfortunately, the demoted tools do not only use tiffconf.h. Some of them rely heavily on libtiff internals. It wouldn't be a simple process to separate the tools from the rest of libtiff.

I didn't realize that. I think that is worth fixing.

The utilities can't be examples of best use of libtiff if they access libtiff internals that normal applications can't use.

Possibly other users of libtiff are forced into accessing the same libtiff internals, and it might help libtiff users if everything required to implement the utilities was part of the stable public api. Is it more complicated than trying to build the utilities with just the public header files to see what breaks, and then moving some declarations or wrappers to access them to a public header?

Fork libtiff

How about setting up the utilities as a git repo that builds with libtiff as a submodule?

The utilities would be able to reference a specific commit of libtiff, so they could access libtiff internals safely.

I have been trying to rally people interested in doing the work to fix the security issues.

I could probably handle an occasional request with a cve and example tiff that is reproducible on Linux x86_64.

William