Re: [Tiff] Remove TIFFCROP from LibTiff + tiff2ps & tiff2pdf ?

[Kurt Schwehr]

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 ?

[Daniel McCoy]

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 ?

[miguel medalha]

> 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 ?

[Even Rouault]

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 ?

[Rob Boehne via Tiff]

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
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 ?

[Kurt Schwehr]

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 ?

[Bob Friesenhahn]

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 ?

[Even Rouault]

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 ?

[Even Rouault]

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