Re: [Tiff] Call for discussion: RFC 2: Restoring needed libtiff tools

[Kurt Schwehr via Tiff]

Does the tiff project have Coverity setup? It might be good to have since
GDAL's Coverity runs will not check any of the tiff tools.

On Fri, Apr 19, 2024 at 1:35 AM Sulau via Tiff  wrote:

> Hi,
>
> I've drafted a proposal for request for comment (RFC) at
> https://gitlab.com/libtiff/libtiff/-/merge_requests/581.
>
> Please provide feedback either within the merge request or via e-mail
> reply.
>
>
> Guidelines for the response to RFCs can be found at:
> https://libtiff.gitlab.io/libtiff/rfcs/rfc1_psc.html
>
>
> Summary:
> 
> The purpose of this RFC is to clarify if and which tools that were moved to
> the archive in libtiff 4.6.0 should be reactivated.
>
> Prehistory:
> -
> The very old and unmaintained tools in libtiff caused many vulnerabilities
> and CVEs that were attributed to the libtiff library itself.
> Trying to fix the security holes in the tools turned out to be a Sisyphean
> task (can never be done).
> Therefore, most of the tools in libtiff 4.6.0 were moved to the archive and
> the existing problems were closed with "wontfix-unmaintained".
>
> It was later understood that some users depend on some of these archived
> tools.
>
> Some problems with the tools have now been fixed (see e.g.
> https://gitlab.com/libtiff/libtiff/-/merge_requests/569).
>
>
> Proposed Procedure:
> -
> -   Only the required tools should be activated. These are: fax2ps,
> tiff2bw, tiff2pdf, tiff2ps
> as well as the already active tools tiffcp, tiffdither, tiffdump,
> tiffinfo, tiffset, tiffsplit.
>
> -   Thus following tools will not be restored and will remain in the
> archive: fax2tiff, pal2rgb, ppm2tiff,
> raw2tiff, rgb2ycbcr, thumbnail, tiff2rgba, tiffcmp, tiffcrop,
> tiffgt, tiffmedian.
>
> -   Bugfixes in MR !569 are applied in single merge requests for
> traceability and selectively
> as some changes might not be applicable.
>
> -   Remove "wontfix-unmaintained" from closed issues, when fixed.
>
> -   All issues related to utilities / tools shall get label "utility".
>
> -   The documentation and other references shall point to
> https://libtiff.gitlab.io/libtiff/.
>
> -   After an initial merge has been applied for restoring the tools,
> the
> www.libtiff.org page
> shall be reset as a mirror of https://libtiff.gitlab.io/libtiff/.
>
> -   Finally release as 4.7.0 when all known issues of the tools are
> closed.
>
> References to previous contributions to the discussion:
> --
>   https://gitlab.com/libtiff/libtiff/-/issues/580 and related merge
> request
>   https://www.asmail.be/msg0054917226.html
>   https://www.asmail.be/msg0055015786.html
>   https://gitlab.com/libtiff/libtiff/-/merge_requests/569
>
> Regards
> Su
>
> ___
> 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] Motion: adopt RFC 1: Project Steering Committee Guidelines

[Kurt Schwehr via Tiff]

+1 KurtS (as a user of libtiff)

On Fri, Mar 22, 2024 at 2:37 AM Even Rouault via Tiff 
wrote:

> Hi,
>
> as discussed in recent weeks, this formalizes the way the Project Steering
> Committee will operate, and bootstrap it. The proposed text is in
> https://gitlab.com/libtiff/libtiff/-/merge_requests/566 and as the
> discussion around it has settled down, it is now time to vote on it.
>
> As in any bootstrapping process, we have no official rules yet. We should
> likely aim for a unanimity vote from at least the proposed PSC members, and
> ideally a majority from the expressed votes of the community member who may
> want to cast their vote.
>
> Starting with my +1 (with the meaning indicated in the RFC "support for
> the proposal and a willingness to support implementation")
>
> Note: one topic of work for the near future will be to see how we can try
> to conciliate the various needs of the community, in particular regarding
> the future of the command line utilities.
>
> Even
>
> -- 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] Proposition for the creation of a libtiff project steering committee

[Kurt Schwehr via Tiff]

I'm +1 for the idea. I appreciate the documentation and structure that PSCs
bring to the projects over the long term.

My related background for context:

- I'm on the PSCs for https://gdal.org/ and https://proj.org/
- I was a packager for fink  (debian on Mac OSX)
for ~20 years. I mostly did C/C++/Python geospatial packages
- I am an "owner" of the third_party/tiff part of Google's internal google3
monorepo with millions of dependencies on the package

-Kurt

On Tue, Feb 27, 2024 at 7:08 AM Even Rouault via Tiff 
wrote:

> Dear libtiff community,
>
> The libtiff project has run for many years without a formal governing
> body, and while it has worked well for most of the time, when difficult
> non-consensual decisions have to be made, it has showed its limits.
> Recently this was the case for the removal in the default build of the
> retired TIFF command line utilities. Hence with a group of other
> stakeholders including me, Su Laus, Bob Friesenhahn, Leonard Rosenthol,
> Roger Leigh, Olivier Paquet and Timothy Lyanguzov, we are proposing to form
> a Project Steering Committee (PSC) for libtiff, with us as the initial
> members of the PSC. That committee would have voting powers to make
> decisions on behalf of the project. This is a structure that is heavily
> used in most of the projects affiliated with the Open Source Geospatial
> Foundation (OSGeo) in the geospatial field where I'm involved. A rather
> successful model for the working and scope of such a committee is for
> example the one used by the GDAL (
> https://gdal.org/development/rfc/rfc1_pmc.html) and MapServer (
> https://mapserver.org/development/rfc/ms-rfc-23.html ) projects since 2007
>
> Those rules have served well those projects in the last 17 years, and  can
> handle situations where PSC members become inactive without formally
> resigning (the PSC can of course also decide to formally remove members
> that no longer participate). So we are considering taking strong
> inspiration from them for the working of the libtiff PSC . In the
> adaptations that have been discussed between us, the 2 business day minimum
> delay indicated for formal votes is probably too short given libtiff usual
> pace and could be extended to 5. For GDAL and MapServer, we also
> traditionally put adoption of release candidates as final approved releases
> to a PSC vote.  It could be discussed if we'd want to do that for libtiff
> too. For the concrete mode of operation, typically in GDAL, when a formal
> decision has to be made, there is a first round of emails "Call for
> discussion: topic ", and once the discussion seems to have come to a
> conclusion there's a "Motion: decision " where PSC members cast their
> +1, +0, 0, -0, -1 votes.
>
> One advantage of the PSC is that difficult decisions are made on behalf on
> the group, which avoids them to be borne by individuals. Having a PSC
> doesn't obviously exclude trying to reach consensus among the broader
> community. Not everything needs to be formally discussed and voted. Normal
> bug-fixing or "small" new features can be dealt in merge requests as usual,
> and don't require email traffic. But removing tools or functionality, break
> of backward compatibility, or significant addition of new functionality are
> topics for discussion and formal votes.
>
> So, this email is to gather feedback from the libtiff community at large
> to check if the idea of a PSC, and its proposed initial membership, makes
> sense. If people would like to be included to the initial PSC, they can
> (possibly privately) reach to us, so we can discuss this possibility.
>
> Best regards,
>
> -- 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] 4.5.1 release soon

[Kurt Schwehr]

I've now tested through 46ea8e2a5c5943b97b9f077b4eda80a600c076cd and I
haven't run into any trouble.

On Mon, Jun 5, 2023 at 9:27 AM Kurt Schwehr  wrote:

> Thanks Even!
>
> For my non-standard/custom bazel build of libtiff, I have tested
> everything in google3 with libtiff head except for
> https://gitlab.com/libtiff/libtiff/commit/46ea8e2a5c5943b97b9f077b4eda80a600c076cd,
> which is in testing today
>
> On Mon, Jun 5, 2023 at 8:41 AM Even Rouault 
> wrote:
>
>> Hi,
>>
>> I plan to do a 4.5.1 release soon
>> (https://gitlab.com/libtiff/libtiff/-/merge_requests/496 is the last bit
>> I want to have in this release), probably end of this week / beginning
>> of next week, so this is a good time for people to test master and check
>> if things are OK
>>
>> Even
>>
>> --
>> 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] 4.5.1 release soon

[Kurt Schwehr]

Thanks Even!

For my non-standard/custom bazel build of libtiff, I have tested everything
in google3 with libtiff head except for
https://gitlab.com/libtiff/libtiff/commit/46ea8e2a5c5943b97b9f077b4eda80a600c076cd,
which is in testing today

On Mon, Jun 5, 2023 at 8:41 AM Even Rouault 
wrote:

> Hi,
>
> I plan to do a 4.5.1 release soon
> (https://gitlab.com/libtiff/libtiff/-/merge_requests/496 is the last bit
> I want to have in this release), probably end of this week / beginning
> of next week, so this is a good time for people to test master and check
> if things are OK
>
> Even
>
> --
> 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]

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 ?

[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] rc3 is available (was Re: [gdal-dev] libtiff v4.5.0 rc2 available)

[Kurt Schwehr]

I've made it to
https://gitlab.com/libtiff/libtiff/commit/193c94b30ca5c7720454a786672ec48718ef3698
the >1M tests all work.

Just starting on c2a28a12.  It's a smoke test of 1K tests.  I should know
the rest in about 12 hours.

On Tue, Dec 13, 2022 at 2:36 PM Even Rouault 
wrote:

> Here's RC3 with the fix for the issue Kurt raised (and a few relatted
> formatting printf() tidy up):
>
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc3.tar.gz
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc3.tar.gz.sig
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc3.tar.xz
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc3.tar.xz.sig
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc3.zip
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc3.zip.sig
>
> Le 13/12/2022 à 21:39, Even Rouault a écrit :
> > Hi,
> >
> > The changes in IFD loop detection are non-trivial enough to justify a
> > rc2, so here it is:
> >
> > - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.gz
> > - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.gz.sig
> > - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.xz
> > - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.xz.sig
> > - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.zip
> > - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.zip.sig
> >
> > Hopefully this will be the final release candidate for 4.5.0. Please
> > test and report.
> >
> > The changes since rc1 are:
> > - restore formatting of tiffvers.h so that FindTIFF.cmake can infer
> > libtiff version number
> > - addition of TIFFLIB_MAJOR_VERSION, TIFFLIB_MINOR_VERSION,
> > TIFFLIB_MICRO_VERSION in tiffvers.h
> > - introduction of TIFFLIB_AT_LEAST(major, minor, micro) macro in
> > tiffvers.h
> > - CMake: restore BUILD_SHARED_LIBS=ON default setting for top-level
> > builds
> > - IFD loop detection: changed algorithm to use a hashset/hashmap for
> > good performance
> > - tdir_t type updated to uint32_t. This type is now used for the
> > return value of TIFFCurrentDirectory and TIFFNumberOfDirectories, and
> > as the argument of TIFFSetDirectory and TIFFUnlinkDirectory
> > - Increase the maximum number of IFDs that libtiff can browse through
> > from 65535 to 1048576. This value is a build-time setting, available
> > in tif_config.h, that can be configured with CMake's
> > TIFF_MAX_DIR_COUNT and variable or autoconf's --with-max-dir-count
> > option.
> > - tiffinfo: support more than 64k IFDs.
> >
> > Even
> >
> --
> 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] libtiff v4.5.0 rc2 available

[Kurt Schwehr]

I patched that in and it works for me.

Thanks!

On Tue, Dec 13, 2022 at 1:47 PM Even Rouault 
wrote:

> Hi Kurt,
>
> thanks for the feedback (and invalidating my prophecy that rc2 would be
> the last one :-))
>
> should be fixed with
> https://gitlab.com/libtiff/libtiff/-/merge_requests/444.
>
> Is that enough to get the build working for you before I generate a rc3
> with that extra fix ?
>
> Even
> Le 13/12/2022 à 22:39, Kurt Schwehr a écrit :
>
> I'm seeing mac osx and ios failures at my most recent sync of
> c4516f9dc72bad7f2c4a8f704169afa0342e44ca
> <https://www.google.com/url?sa=D=https%3A%2F%2Fgitlab.com%2Flibtiff%2Flibtiff%2Fcommit%2Fc4516f9dc72bad7f2c4a8f704169afa0342e44ca>:
>
>
> third_party/tiff/libtiff/tif_dir.c:1988:17: error: format specifies type
> 'unsigned short' but the argument has type 'tdir_t' (aka 'unsigned int')
> [-Werror,-Wformat]
> *nextdirnum, *nextdiroff, *nextdiroff, (int)(*nextdirnum)
> - 1);
> ^~~
> third_party/tiff/libtiff/tif_dir.c:2164:27: error: format specifies type
> 'unsigned short' but the argument has type 'tdir_t' (aka 'unsigned int')
> [-Werror,-Wformat]
>   dirn);
>   ^~~~
>
>
>
> On Tue, Dec 13, 2022 at 12:39 PM Even Rouault 
> wrote:
>
>> Hi,
>>
>> The changes in IFD loop detection are non-trivial enough to justify a
>> rc2, so here it is:
>>
>> - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.gz
>> - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.gz.sig
>> - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.xz
>> - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.xz.sig
>> - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.zip
>> - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.zip.sig
>>
>> Hopefully this will be the final release candidate for 4.5.0. Please
>> test and report.
>>
>> The changes since rc1 are:
>> - restore formatting of tiffvers.h so that FindTIFF.cmake can infer
>> libtiff version number
>> - addition of TIFFLIB_MAJOR_VERSION, TIFFLIB_MINOR_VERSION,
>> TIFFLIB_MICRO_VERSION in tiffvers.h
>> - introduction of TIFFLIB_AT_LEAST(major, minor, micro) macro in
>> tiffvers.h
>> - CMake: restore BUILD_SHARED_LIBS=ON default setting for top-level builds
>> - IFD loop detection: changed algorithm to use a hashset/hashmap for
>> good performance
>> - tdir_t type updated to uint32_t. This type is now used for the return
>> value of TIFFCurrentDirectory and TIFFNumberOfDirectories, and as the
>> argument of TIFFSetDirectory and TIFFUnlinkDirectory
>> - Increase the maximum number of IFDs that libtiff can browse through
>> from 65535 to 1048576. This value is a build-time setting, available in
>> tif_config.h, that can be configured with CMake's TIFF_MAX_DIR_COUNT and
>> variable or autoconf's --with-max-dir-count option.
>> - tiffinfo: support more than 64k IFDs.
>>
>> Even
>>
>> --
>> 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
>>
> -- 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] libtiff v4.5.0 rc2 available

[Kurt Schwehr]

I'm seeing mac osx and ios failures at my most recent sync of
c4516f9dc72bad7f2c4a8f704169afa0342e44ca

:

third_party/tiff/libtiff/tif_dir.c:1988:17: error: format specifies type
'unsigned short' but the argument has type 'tdir_t' (aka 'unsigned int')
[-Werror,-Wformat]
*nextdirnum, *nextdiroff, *nextdiroff, (int)(*nextdirnum) -
1);
^~~
third_party/tiff/libtiff/tif_dir.c:2164:27: error: format specifies type
'unsigned short' but the argument has type 'tdir_t' (aka 'unsigned int')
[-Werror,-Wformat]
  dirn);
  ^~~~



On Tue, Dec 13, 2022 at 12:39 PM Even Rouault 
wrote:

> Hi,
>
> The changes in IFD loop detection are non-trivial enough to justify a
> rc2, so here it is:
>
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.gz
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.gz.sig
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.xz
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.xz.sig
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.zip
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc2.zip.sig
>
> Hopefully this will be the final release candidate for 4.5.0. Please
> test and report.
>
> The changes since rc1 are:
> - restore formatting of tiffvers.h so that FindTIFF.cmake can infer
> libtiff version number
> - addition of TIFFLIB_MAJOR_VERSION, TIFFLIB_MINOR_VERSION,
> TIFFLIB_MICRO_VERSION in tiffvers.h
> - introduction of TIFFLIB_AT_LEAST(major, minor, micro) macro in tiffvers.h
> - CMake: restore BUILD_SHARED_LIBS=ON default setting for top-level builds
> - IFD loop detection: changed algorithm to use a hashset/hashmap for
> good performance
> - tdir_t type updated to uint32_t. This type is now used for the return
> value of TIFFCurrentDirectory and TIFFNumberOfDirectories, and as the
> argument of TIFFSetDirectory and TIFFUnlinkDirectory
> - Increase the maximum number of IFDs that libtiff can browse through
> from 65535 to 1048576. This value is a build-time setting, available in
> tif_config.h, that can be configured with CMake's TIFF_MAX_DIR_COUNT and
> variable or autoconf's --with-max-dir-count option.
> - tiffinfo: support more than 64k IFDs.
>
> Even
>
> --
> 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] libtiff v4.5.0 release candidate available

[Kurt Schwehr]

I'm a couple commits back from head and have no known issues.  I pull
directly via git head and use bazel for building, so I can't comment about
the tar / zip.

Specifically, I'm at
https://gitlab.com/libtiff/libtiff/-/commit/1bdbd03fbb4e7d662af052450259fcd353a49cc0
and working on updating my patches to the new formatting.

On Fri, Dec 9, 2022 at 7:48 AM Even Rouault 
wrote:

> Hi,
>
> I've prepared a release candidate for libtiff v4.5.0:
>
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc1.tar.gz
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc1.tar.gz.sig
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc1.tar.xz
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc1.tar.xz.sig
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc1.zip
> - https://download.osgeo.org/libtiff/tiff-4.5.0rc1.zip.sig
>
> Release notes at https://libtiff.gitlab.io/libtiff/releases/v4.5.0.html
>
> I'll promote it to final next week if no serious blocking issues are
> reported.
>
> Thanks to all contributors.
>
> Best regards,
>
> --
> 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] Code base reformatting

[Kurt Schwehr]

I for one will have to rework 14 patches that I have to carry on our local
libtiff in Google.  From my point of view, it would be a huge benefit
having the whole codebase reformatted for consistency.  I see the current
inconsistency in every commit to libtiff as I review all of the diffs for
the library side of the code.

-kurt

On Tue, Dec 6, 2022 at 11:41 AM Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:

> On Tue, 6 Dec 2022, Even Rouault wrote:
> >
> > Hoping for no strong opposition and religious discussions about code
> > formatting preferences, I'll merge this soon.
>
> I expect that there will be much anger from those hoping to produce
> useful patches for older libtiff directly from libtiff source code.
>
> There will be initial pain but patches produced from that point
> forward should be much cleaner.
>
> 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

Re: [Tiff] clarification on the fix status for new CVE-2022-3570?

[Kurt Schwehr]

Hi Ellen,

A side note:  (I'm pretty sure I've shared this in the past, but I can't
remember where)

I use libtiff from head for Google.  That way...

- can report any troubles right away back to the maintainers and reports
and patches are easier
- usually ahead of the CVE game.  CVEs have not been helpful to me
- There are enough tests in our system that each update does a pretty good
job of exercising libtiff.  While MatLab isn't the size of google3, it's
probably big enough to have good confidence in deploying tiff from head.
- I have a pretty large fuzzer generated corpus that gets checked daily in
asan and msan mode.  It's not hard to make your own corpus e.g.
gtiff_fuzzer.cc

which
is apache 2.0 licensed and the fuzzers in the gdal code base.
- never have to ask for a point releases

As always, thanks to everyone who contributes to libtiff!

-kurt


On Fri, Nov 4, 2022 at 2:12 PM Ellen Johnson  wrote:

> Hi Su and libtiff folks,
>
>   We just received a slew of 16 libtiff CVEs reported to us by a large
> customer – this is in addition to CVE-2022-3570 I previously wrote about.
> I see most of these CVEs are fixed in the libtiff master branch but not yet
> in an official release.
>
>   I have two questions:
>
>1. Can anyone provide an update on an estimated release timeframe for
>a libtiff version (presumably 4.5.0) containing all the CVE fixes that have
>been successfully integrated into libtiff master branch since release of
>4.4.0?
>2. For newly reported CVE-2022-34266 in
>https://nvd.nist.gov/vuln/detail/CVE-2022-34266:  I’m confused about
>this one.  It states there’s a vulneratbility in TIFFFetchStripThing in
>tif_dirread.c in the libtiff-4.0.3-35.amzn2.0.1 package for LibTIFF on
>Amazon Linux 2, and states it’s a different vulnerability than
>CVE-2022-0562.  The NVD report for CVE-2022-34266 doesn’t contain any links
>to a libtiff GitLab issue describing the vulnerability, but I do see that
>the libtiff fix for CVE-2022-0562 was released in 4.4.0.  Can you please
>let me know if CVE-2022-34266 is a new vulnerability that’s different from
>CVE-2022-0562 as stated in the NVD CVE report?
>
>   Thank you,
>
> ellen
>
>
>
> *From:* Ellen Johnson
> *Sent:* Wednesday, October 26, 2022 5:50 PM
> *To:* Sulau ; tiff@lists.osgeo.org
> *Subject:* RE: [Tiff] clarification on the fix status for new
> CVE-2022-3570?
>
>
>
> Hi Su,
>
>   Thank you so much for clarifying.
>
>   Do you have an estimate on the timeframe for release of 4.5.0?
>
>   Thanks,
>
>  ellen
>
>
>
> *From:* Sulau 
> *Sent:* Wednesday, October 26, 2022 4:51 PM
> *To:* tiff@lists.osgeo.org
> *Cc:* Ellen Johnson 
> *Subject:* AW: [Tiff] clarification on the fix status for new
> CVE-2022-3570?
>
>
>
> Hi Ellen,
>
>
>
> issues 381 and 386 are fixed and related MR is merged into the master
> branch one week ago. So they will probably be released with next version
> 4.5.0
>
>
>
> Regards,
>
> Su
>
>
>
> *Von:* Tiff [mailto:tiff-boun...@lists.osgeo.org
> ] *Im Auftrag von *Ellen Johnson
> *Gesendet:* Montag, 24. Oktober 2022 19:05
> *An:* tiff@lists.osgeo.org
> *Betreff:* [Tiff] clarification on the fix status for new CVE-2022-3570?
>
>
>
> Hi libtiff developers,
>
>
>
>   I’m confused about the new CVE reported in libtiff >= 4.4.0 related to
> the previous CVEs in tiffcrop.c.  There’s a lot of comments in the GitLab
> issues and I’m trying to detangle whether this is fixed in 4.4.0, or in the
> master branch waiting to be released into a new libtiff version, or still
> open and not yet merged into any branch.
>
> NVD link:  https://nvd.nist.gov/vuln/detail/CVE-2022-3570
>
> Related libtiff GitLab issue:
> https://gitlab.com/gitlab-org/cves/-/issues/479
>
>
>
>   From the GitLab posts and merge requests, it looks like it’s related to
> the previous CVEs fixed in
> https://gitlab.com/libtiff/libtiff/-/merge_requests/382.
>
>   In these two GitLab issues, the CVE reporter is saying they are still
> open issues in 4.4.0:
>
> https://gitlab.com/libtiff/libtiff/-/issues/381
>
> https://gitlab.com/libtiff/libtiff/-/issues/386
>
>
>
>   Can you please advise on the fix status for
> https://nvd.nist.gov/vuln/detail/CVE-2022-3570?
>
>   Thank you!
>
>  ellen
>
>
> ___
> 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] libtiff v4.4.0 RC1 available

[Kurt Schwehr]

Totally agree.  The issue is definitely *NOT* the responsibility of
libtiff.  Just trying to document the issue for folks who may have hit it.
The most recent file in https://sourceforge.net/projects/freeimage/files/
is 2018 and the project doesn't look to be active (e.g. it has a cvs repo
that is now read only on sourceforge and I didn't see an official spot on
github)

On Fri, May 20, 2022 at 11:04 AM Even Rouault 
wrote:

> Kurt,
>
> The _TIFFDataSize() symbol that Freeimage used was in the private &
> non-installed tiffiop.h header, so they weren't supposed to use it. I also
> suspect that their code might not have linked on Windows.
>
> Even
> Le 20/05/2022 à 19:56, Kurt Schwehr a écrit :
>
> Thanks Even!
>
> I can't comment on the point release RC directly, but...
>
> I've been using libtiff from head (with my own bazel based build system +
> my own mods to the generated headers) and have not heard any reports of
> trouble across the huge number of targets that use it.
>
> The only issue I ran into was with https://freeimage.sourceforge.io/.
> Here is the patch I used.  I only have one version of libtiff, so I didn't
> have to worry about making this an ifdef.
>
> diff -ru a/files/Source/Metadata/XTIFF.cpp
> b/files/Source/Metadata/XTIFF.cpp
> --- a/files/Source/Metadata/XTIFF.cpp 2022-05-18 06:56:41.578314458 -0700
> +++ b/files/Source/Metadata/XTIFF.cpp 2022-05-18 12:51:56.674454816 -0700
> @@ -749,7 +749,7 @@
>   continue;
>   }
>   // type of storage may differ (e.g. rationnal array vs float array type)
> - if((unsigned)_TIFFDataSize(tif_tag_type) !=
> FreeImage_TagDataWidth(tag_type)) {
> + if((unsigned)TIFFFieldSetGetSize(fld) !=
> FreeImage_TagDataWidth(tag_type)) {
>   // skip tag or _TIFFmemcpy will fail
>   continue;
>   }
>
> I've sent this to free image, so they can make a proper patch if they want:
>
>
> https://sourceforge.net/p/freeimage/discussion/36109/thread/2018fdc6e7/#393d
>
> -kurt
>
> On Fri, May 20, 2022 at 9:38 AM Even Rouault 
> wrote:
>
>> Hi,
>>
>> I've prepare a release candidate for libtiff v4.4.0:
>>
>> - https://download.osgeo.org/libtiff/tiff-4.4.0rc1.tar.gz
>>
>> - https://download.osgeo.org/libtiff/tiff-4.4.0rc1.tar.gz.sig
>>
>> - https://download.osgeo.org/libtiff/tiff-4.4.0rc1.tar.xz
>>
>> - https://download.osgeo.org/libtiff/tiff-4.4.0rc1.tar.xz.sig
>>
>> - https://download.osgeo.org/libtiff/tiff-4.4.0rc1.zip
>>
>> - https://download.osgeo.org/libtiff/tiff-4.4.0rc1.zip.sig
>>
>> Release notes at https://libtiff.gitlab.io/libtiff/v4.4.0.html
>>
>> I'll promote it to final next week if no serious blocking issues are
>> reported.
>>
>> Best regards,
>>
>> --
>> 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
>>
> -- 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] libtiff v4.4.0 RC1 available

[Kurt Schwehr]

Thanks Even!

I can't comment on the point release RC directly, but...

I've been using libtiff from head (with my own bazel based build system +
my own mods to the generated headers) and have not heard any reports of
trouble across the huge number of targets that use it.

The only issue I ran into was with https://freeimage.sourceforge.io/. Here
is the patch I used.  I only have one version of libtiff, so I didn't have
to worry about making this an ifdef.

diff -ru a/files/Source/Metadata/XTIFF.cpp b/files/Source/Metadata/XTIFF.cpp
--- a/files/Source/Metadata/XTIFF.cpp 2022-05-18 06:56:41.578314458 -0700
+++ b/files/Source/Metadata/XTIFF.cpp 2022-05-18 12:51:56.674454816 -0700
@@ -749,7 +749,7 @@
  continue;
  }
  // type of storage may differ (e.g. rationnal array vs float array type)
- if((unsigned)_TIFFDataSize(tif_tag_type) !=
FreeImage_TagDataWidth(tag_type)) {
+ if((unsigned)TIFFFieldSetGetSize(fld) !=
FreeImage_TagDataWidth(tag_type)) {
  // skip tag or _TIFFmemcpy will fail
  continue;
  }

I've sent this to free image, so they can make a proper patch if they want:

https://sourceforge.net/p/freeimage/discussion/36109/thread/2018fdc6e7/#393d

-kurt

On Fri, May 20, 2022 at 9:38 AM Even Rouault 
wrote:

> Hi,
>
> I've prepare a release candidate for libtiff v4.4.0:
>
> - https://download.osgeo.org/libtiff/tiff-4.4.0rc1.tar.gz
>
> - https://download.osgeo.org/libtiff/tiff-4.4.0rc1.tar.gz.sig
>
> - https://download.osgeo.org/libtiff/tiff-4.4.0rc1.tar.xz
>
> - https://download.osgeo.org/libtiff/tiff-4.4.0rc1.tar.xz.sig
>
> - https://download.osgeo.org/libtiff/tiff-4.4.0rc1.zip
>
> - https://download.osgeo.org/libtiff/tiff-4.4.0rc1.zip.sig
>
> Release notes at https://libtiff.gitlab.io/libtiff/v4.4.0.html
>
> I'll promote it to final next week if no serious blocking issues are
> reported.
>
> Best regards,
>
> --
> 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] Request bug confirmation for libtiff

[Kurt Schwehr]

I suggest moving the discussion to the bug as I asked the same there.

On Thu, May 5, 2022 at 11:29 AM Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:

> On Thu, 5 May 2022, jeshrz wrote:
>
> > Hi,
> >
> >
> > I recently report a bug issue of libtiff in GitLab.
> >
> >
> > I will appreciate it if you could confirm this issue since this is my
> homework which developer feedback is required.
>
> Certainly, the bug you opened is in the system.
>
> Did you verify that it is present in the current Git version?
>
> 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