>If the utilities are again maintained by the libtiff project, they need to be in a separate repository, with its own build process
Shouldn't the build for the utilities be simpler than the build for libtiff because the utilities only use tiffconf.h instead of generating it? The utilities should be best use examples for libtiff, and something might be wrong if they end up needing a massively complicated build process. William ________________________________ From: Tiff <tiff-boun...@lists.osgeo.org> on behalf of Rob Tillaart via Tiff <tiff@lists.osgeo.org> Sent: Sunday, February 4, 2024 9:09 AM To: Bob Friesenhahn <bfrie...@simple.dallas.tx.us> Cc: Patrice Fournier via Tiff <tiff@lists.osgeo.org> Subject: Re: [Tiff] www.libtiff.org is restored > If the utilities are again maintained by the libtiff project, they need to be in a separate repository, with its own build process, and released distinctly from libtiff. If this approach is not acceptable to libtiff maintainers, then the tools would need to be hosted elsewhere. Agree, maybe even create a project per tool? my 2 cents, Rob On Sun, Feb 4, 2024 at 2:59 PM Bob Friesenhahn via Tiff <tiff@lists.osgeo.org<mailto:tiff@lists.osgeo.org>> wrote: On Sat, 3 Feb 2024, Patrice Fournier via Tiff wrote: > > This would be really helpful indeed! I was already looking at my teams (iFAX > Solutions (HylaFAX Enterprise and HylaFAX), but also T38Fax which uses these > tools internally) to spare some time to work on this, but first, we'll need > to know where to work on this and where to handle the issues. We'd personally > prefer it be in the libtiff project, either in the main project, master > branch or at minimum a separate branch from which (security issues) fixed > tools are merged back into master. This would require all tools bugs to be > restored and `wontfix-unmaintained` tags changed to `tools` or something like > that, from which we could identify/label security issues and know which ones > to concentrate on for this task (and the main libtiff team could exclude in > their buglist if they so prefer, until we made enough progress). It is useful to be aware of the underlying reasons why utilities were removed from libtiff. Whenever a security issue is identified related to software produced by the libtiff project, a CVE was created against libtiff, since the utility was released as part of libtiff. Proprietary and free operating system and application distributions which include libtiff then had a huge red flag assigned to them, which demands action. The utilities were continually having CVEs at the most severe levels written against them. It is also a fact that several people maintaining core libtiff primarily care about the library and not these old utilities. If the utilities are again maintained by the libtiff project, they need to be in a separate repository, with its own build process, and released distinctly from libtiff. If this approach is not acceptable to libtiff maintainers, then the tools would need to be hosted elsewhere. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us<mailto:bfrie...@simple.dallas.tx.us>, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt _______________________________________________ Tiff mailing list Tiff@lists.osgeo.org<mailto:Tiff@lists.osgeo.org> https://lists.osgeo.org/mailman/listinfo/tiff
_______________________________________________ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
