>  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> 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, 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
> https://lists.osgeo.org/mailman/listinfo/tiff
>
_______________________________________________
Tiff mailing list
Tiff@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/tiff

Reply via email to