Re: [Tiff] Remove TIFFCROP from LibTiff

2023-04-07 Thread Bob Friesenhahn

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

2023-04-06 Thread Even Rouault


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

2023-04-06 Thread miguel medalha
> 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

2023-04-06 Thread Even Rouault
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

2023-04-05 Thread Sulau
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 ?

2023-04-04 Thread 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 ?

2023-04-04 Thread 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 ?

2023-04-04 Thread 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 ?

2023-04-04 Thread 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 ?

2023-04-04 Thread 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<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 ?

2023-04-04 Thread 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 ?

2023-04-04 Thread 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 ?

2023-04-04 Thread 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 ?

2023-04-04 Thread 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


[Tiff] Remove TIFFCROP from LibTiff

2023-04-03 Thread Sulau
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