For my use case, we have customers who look at a software bill of materials (BOM), and flag any “product” that has any CVE reported against any part of it. So even though we only use libtiff, and we explain that to our clients, and it’s in our BOM, we end up having to either update or explain to each client how the specific CVE isn’t in our product. Separating tools into another repository would likely eliminate this problem. If we don’t have volunteers to maintain the tools, then we probably don’t have people that want to use them.
From: Tiff <[email protected]> on behalf of Kurt Schwehr <[email protected]> Date: Tuesday, April 4, 2023 at 10:14 AM To: Even Rouault <[email protected]> Cc: Tiff List <[email protected]> Subject: Re: [Tiff] Remove TIFFCROP from LibTiff + tiff2ps & tiff2pdf ? I personally exclude all the programs from my distribution of libtiff to run into fewer CVEs. Another alternative to consider is putting a disclaimer on those tools saying that CVEs might not be fixed and use at your own risk. Many pipelines use only trusted data, so they are fine. And folks using untrusted data, should be running their pipelines in a security sandbox. Setting up sandboxes is definitely a user responsibility. On Tue, Apr 4, 2023, 7:05 AM Even Rouault <[email protected]<mailto:[email protected]>> wrote: > There is the possibility to create a separate project/package for > these "unmaintainable" libtiff utilities in order to significantly > lessen the degree of distress on libtiff itself but still allow these > utilities to be maintained, and released on a different schedule and > by perhaps different volunteers. To me this seems better than to > create more dead source code in the libtiff package. That's an alternative I considered. But who are those potential contributors to which we would give the "keys" of the repo ? In the absence of people stepping up to create & maintain such repository for those tiff tools, moving the code to archive/ could be a first step to preserve the source code, and if someone wants to resurrect it, they can start from that and we would remove it completely from libtiff itself at that point. -- http://www.spatialys.com My software is free, but my time generally not. _______________________________________________ Tiff mailing list [email protected]<mailto:[email protected]> https://lists.osgeo.org/mailman/listinfo/tiff
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
