4.7.2 release preparation in
https://gitlab.com/libtiff/libtiff/-/merge_requests/905
Le 17/06/2026 à 22:56, William Bader via Tiff a écrit :
> as easier than explaining to people why they shouldn't be upset
about CVE numbers.
Some distributions have issues with packages that have known CVEs.
> a similarly large number of proposed change-sets.
Is it possible to reject any change-set that doesn't include a sample
image and a test driver that proves that the issue really exists and
that the change-set fixes it?
Is it possible to review the change-sets with an LLM?
For memory-related DoS issues, is it possible to add an api to set a
flag that rejects large allocations? Then someone scripting gm for
small images or using libtiff to display small images would be safe
from images that are accidentally large, or maliciously large, or
corrupt. By large, I mean more than around 150MB, which is enough for
a 300dpi 8-bit per component CMYK image the size of a broadsheet
newspaper page.
William
------------------------------------------------------------------------
*From:* Tiff <[email protected]> on behalf of Greg Troxel
via Tiff <[email protected]>
*Sent:* Wednesday, June 17, 2026 2:46 PM
*To:* Bob Friesenhahn <[email protected]>
*Cc:* Kurt Schwehr via Tiff <[email protected]>
*Subject:* Re: [Tiff] release status, CVE
Bob Friesenhahn <[email protected]> writes:
> The change-set you referred to is an attempt to solve a weakness in
libtiff
> which has existed since libtiff was invented (and is common to libraries
> supporting compressed files).
>
> There has recently been an overwhelming flurry of libtiff bug/security
> reports and a similarly large number of proposed change-sets. At
least one
> change-set purports to solve the common reason for many security
reports,
> which is integer value overflow.
I would like to hear your opinion about whether the issues and proposed
changes are LLM generated, and what you think of their quality.
> It is safest to assume that the next libtiff release will occur when
it is
> ready.
I wonder then, as a packager, should I:
Extract a patch from 4.7.1 to HEAD and apply that, calling it
e.g. 4.7.1.50 and make that available to users?
Just take the one commit Even points to, knowing that it's not really
sensible, but as easier than explaining to people why they shouldn't
be upset about CVE numbers. Repeat as necessary when CVEs are
published.
Do nothing for now, and when 4.7.2 comes out, with me not expecting
it, update to it.
Something else?
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
<https://lists.osgeo.org/mailman/listinfo/tiff>
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
--
http://www.spatialys.com
My software is free, but my time generally not.
Burning your AI tokens speeds up global warning.
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
