Re: [Tiff] Remove TIFFCROP from LibTiff
On Fri, 7 Apr 2023, Even Rouault wrote: The source code will remain, but you'll have to build it by yourself. Yes, that's undoubtedly inconvenient, but having unmaintained utilities that bring a endless flock of vulnerabilities that are often misinterpreted as vulnerabilities of the library isn't better for the project. If someone is serious about those utilities, they have to step up and fix them. Most people are not going to have the knowledge or capability to compile these programs outside of libtiff since building them still depends on libtiff build (e.g. Autoconf/Cmake + porting + common-security code) internals. Much more work would need to be done by someone to build the abandoned utilities using an already installed libtiff. This is why a spin-off project makes sense (e.g. staffed by new volunteers). The new project should be prepared to handle the flood of continuing security complaints. 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
Re: [Tiff] Remove TIFFCROP from LibTiff
Le 07/04/2023 à 02:05, miguel medalha a écrit : > I'm leaning towards releasing 4.5.1, with the current state of master, as the last version shipping with tiffcrop, tiff2pdf and tiff2ps > being built with autoconf/cmake, with a warning in the release notes noting they will be moved into archive/tools for 4.6.0. If that is indeed the final decision, can you please point me to other command line tools performing the same functions as tiff2ps and tiff2pdf? Please don't answer "ImageMagick". I very much cherish and heavily use it, but in this case it's just not the same. The source code will remain, but you'll have to build it by yourself. Yes, that's undoubtedly inconvenient, but having unmaintained utilities that bring a endless flock of vulnerabilities that are often misinterpreted as vulnerabilities of the library isn't better for the project. If someone is serious about those utilities, they have to step up and fix them. Even ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff -- http://www.spatialys.com My software is free, but my time generally not. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] Remove TIFFCROP from LibTiff
> I'm leaning towards releasing 4.5.1, with the current state of master, as the > last version shipping with tiffcrop, tiff2pdf and tiff2ps > being built with autoconf/cmake, with a warning in the release notes noting > they will be moved into archive/tools for 4.6.0. If that is indeed the final decision, can you please point me to other command line tools performing the same functions as tiff2ps and tiff2pdf? Please don't answer "ImageMagick". I very much cherish and heavily use it, but in this case it's just not the same. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] Remove TIFFCROP from LibTiff
I'm leaning towards releasing 4.5.1, with the current state of master, as the last version shipping with tiffcrop, tiff2pdf and tiff2ps being built with autoconf/cmake, with a warning in the release notes noting they will be moved into archive/tools for 4.6.0. Even Le 05/04/2023 à 21:11, Sulau a écrit : I would prefer Even’s proposed solution to move problematic tools to archive/tools/. The executables in use are still usable. If individual maintenance is absolutely necessary, the source code is still available (not only in the repository but also in the distribution). Su ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff -- http://www.spatialys.com My software is free, but my time generally not. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] Remove TIFFCROP from LibTiff
I would prefer Even's proposed solution to move problematic tools to archive/tools/. The executables in use are still usable. If individual maintenance is absolutely necessary, the source code is still available (not only in the repository but also in the distribution). Su ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] Remove TIFFCROP from LibTiff + tiff2ps & tiff2pdf ?
Clearly the only sensible thing to do is nuke the CVE system from orbit. It's the only way to be sure. On Tue, Apr 4, 2023, 9:47 AM Daniel McCoy wrote: > People often mention ImageMagick when talking about alternative utilities. > In case anyone here isn't aware of it, I thought I would mention that > Open Image I/O is another alternative open source package. > Its oiiotool utility can perform a lot of handy operations on image files. > > https://openimageio.readthedocs.io/en/v2.4.10.0/ > > > On Tue, Apr 4, 2023 at 8:47 AM miguel medalha wrote: > >> > tiff2ps and tiff2pdf seem to be also good candidates for moving into >> archive as they have a number of reported security related issues and a >> significant code size. Their functionality is (at least mostly) covered by >> the convert utility of ImageMagick. >> >> We use tiff2pdf and tiff2ps intensively as part of the post-processing of >> digitized books, newspapers, and other documents. They are fast and >> effective, and do exactly what we need. Seeing them go would be a real loss. >> ___ >> 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 > ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] Remove TIFFCROP from LibTiff + tiff2ps & tiff2pdf ?
People often mention ImageMagick when talking about alternative utilities. In case anyone here isn't aware of it, I thought I would mention that Open Image I/O is another alternative open source package. Its oiiotool utility can perform a lot of handy operations on image files. https://openimageio.readthedocs.io/en/v2.4.10.0/ On Tue, Apr 4, 2023 at 8:47 AM miguel medalha wrote: > > tiff2ps and tiff2pdf seem to be also good candidates for moving into > archive as they have a number of reported security related issues and a > significant code size. Their functionality is (at least mostly) covered by > the convert utility of ImageMagick. > > We use tiff2pdf and tiff2ps intensively as part of the post-processing of > digitized books, newspapers, and other documents. They are fast and > effective, and do exactly what we need. Seeing them go would be a real loss. > ___ > 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
Re: [Tiff] Remove TIFFCROP from LibTiff + tiff2ps & tiff2pdf ?
> tiff2ps and tiff2pdf seem to be also good candidates for moving into archive > as they have a number of reported security related issues and a significant > code size. Their functionality is (at least mostly) covered by the convert > utility of ImageMagick. We use tiff2pdf and tiff2ps intensively as part of the post-processing of digitized books, newspapers, and other documents. They are fast and effective, and do exactly what we need. Seeing them go would be a real loss. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] Remove TIFFCROP from LibTiff + tiff2ps & tiff2pdf ?
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. I doubt people who have apparently "fun" (*) running fuzzers on libtiff utilities would notice the disclaimer or take it into account. IMHO the best way to stop the flow of security reports on such utilities which annoy libtiff developers and packagers is to no longer make them built by the supported build systems. (*): or perhaps as part of their job, as I suspect libtiff is used as a showcase for some commercial security-related products or research activities. -- http://www.spatialys.com My software is free, but my time generally not. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] Remove TIFFCROP from LibTiff + tiff2ps & tiff2pdf ?
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 on behalf of Kurt Schwehr Date: Tuesday, April 4, 2023 at 10:14 AM To: Even Rouault Cc: Tiff List 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 mailto:even.roua...@spatialys.com>> 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 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
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 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 > 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
Re: [Tiff] Remove TIFFCROP from LibTiff + tiff2ps & tiff2pdf ?
On Tue, 4 Apr 2023, Even Rouault wrote: tiff2ps and tiff2pdf seem to be also good candidates for moving into archive as they have a number of reported security related issues and a significant code size. Their functionality is (at least mostly) covered by the convert utility of ImageMagick. While the original code quality of these libtiff utilities was very poor, it should be consided that some of these utilities are used in existing processing pipelines (e.g. printing subsystems). It should also be considered that a utility like tiff2ps is 5 times more CPU efficient, and 27 times more memory efficient, than using the convert utility of ImageMagick. The tiffcrop utility was used privately in production for years and offers some unique features and performance capabilities not found in other software. Unfortunately, modern security practices were not a consideration when it was written. 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. 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
Re: [Tiff] Remove TIFFCROP from LibTiff + tiff2ps & tiff2pdf ?
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 Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] Remove TIFFCROP from LibTiff + tiff2ps & tiff2pdf ?
Hi, I admire Su's tenacity in trying to fix tiffcrop issues over the past years, and I certainly share his point of view. The vast majority of recent libtiff related CVEs in recent years are not in libtiff itself, but in its utilities. Personally I don't care about libtiff utilities (perhaps except tiffinfo and tiffdump for debugging purposes), just the lib. I guess tiffcrop could receive the same treatment as a few past utilities that have been migrated to archive/tools/ where only the source code is there without any build system support. tiff2ps and tiff2pdf seem to be also good candidates for moving into archive as they have a number of reported security related issues and a significant code size. Their functionality is (at least mostly) covered by the convert utility of ImageMagick. Even Le 03/04/2023 à 22:50, Sulau a écrit : Dear all I have been trying to fix the constant CVE issues at tiffcrop for several years. Today I can say "fixing is not possible". The endless combinable parameters and the grown implementation of the working buffer allocation for input, intermediate results and output make maintenance nearly impossible. Also the code often (partially) does something different than I would expect based on the parameter description. This is then often visible in the resulting image, which looks different than what the very brief parameter description would suggest. With this in mind, I would recommend removing tiffcrop from the LibTiff library to avoid endless CVE and buffer overrun issues that are not really part of LibTiff. Regards Su ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff -- http://www.spatialys.com My software is free, but my time generally not. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
[Tiff] Remove TIFFCROP from LibTiff
Dear all I have been trying to fix the constant CVE issues at tiffcrop for several years. Today I can say "fixing is not possible". The endless combinable parameters and the grown implementation of the working buffer allocation for input, intermediate results and output make maintenance nearly impossible. Also the code often (partially) does something different than I would expect based on the parameter description. This is then often visible in the resulting image, which looks different than what the very brief parameter description would suggest. With this in mind, I would recommend removing tiffcrop from the LibTiff library to avoid endless CVE and buffer overrun issues that are not really part of LibTiff. Regards Su ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff