> Now "http://www.libtiff.org/"; leads to the latest libtiff HTML pages, and the > same server/directory which already provides > "http://www.simplesystems.org/libtiff/";.
With some differences though. The biggest probably being that http://www.libtiff.org advertises a version 4.6.0t with all the tools restored. If I see it right it doesn't fix all the CVEs in those tools though. I believe this can be quite confusing to potential users of tiff. Wouldn't it have been better to first fix the CVEs and then create a new release? Or at least add a note/warning? Especially after the situation with `xz` people are more cautious of what sources they take. Having a kind of fork (https://gitlab.com/faxguy/libtiff-tools meaning libtiff + tools restored) on a website called http://libtiff.org/ (which sounds quite official) that are shipped in a tarball with almost the same name (plus a tiny `t`) is suboptimal in my opinion. The 4.6.0t changelog (http://libtiff.org/releases/v4.6.0t.html) doesn't give much insight either with entries like: > Fix some issues in library found through fuzzing. > Prevent some out-of-memory attacks. It would be good to have the links to the corresponding issues there. Or the CVE names, if applicable. Some of these can be found in https://gitlab.com/faxguy/libtiff-tools. But people need to really look for them. It is rather obscure for people quickly checking the site. And they most likely will not understand what is fixed and what is vulnerable compared to 4.6.0. It would also be great if fixed issues could be linked from the original bugreport in the main upstream repo though I didn't check if this was maybe done in some cases. I think I saw Lee Howard comment on some of the issues but am not sure if it were all. > 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. My colleague Fridrich took a quick look at it and created a POC: https://github.com/fridrich/tiff-tools He copied the few strictly necessary internal macros/prototypes from tiffiop.h into tiff_tools_internal.h. Now only fax2tiff cannot work with the opaque TIFF (struct tiff) type. Maybe some getters and setters exposing the necessary members could be implemented. Maybe this helps the people who would like to bring the tools back and want to take the route of creating a separate tools package. _______________________________________________ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
