There are many TIFF code implementations. Perhaps a start would be to define exactly what "libtiff" is. My view has always been: it is the idiomatic _C_ TIFF library.
Kemp Watson On Tue, 30 Dec 2025 at 12:25, Bob Friesenhahn via Tiff <[email protected]> wrote: > On 12/30/25 08:50, Roger Leigh via Tiff wrote: > > > On top of this, there are some additional considerations. I’ve > mentioned them previously on the list I think. You might have seen the > reporting over the last couple of years about CISA and the phasing-out of > unsafe code from January 2026 onwards: > > > > > https://www.cisa.gov/resources-tools/resources/product-security-bad-practices > > It is worth noting that the CISA documents classify C and C++ the same > due to being "memory-unsafe" languages. Adding C++ to the existing C > will not absolve libtiff from CISA/EU mandates and the "memory-unsafe" > stigma. The underlying operating system (e.g. Linux, *BSD, Solaris, > etc.) is usually written in C. > > The languages Ada, C#, Delphi/Object Pascal, Go, Java, JavaScript (when > used idiomatically), Kotlin, Python, Ruby, Rust, and Swift are on the > lists of memory-safe languages. > > The CVEs for "libtiff" may be found at > https://www.cvedetails.com/product/3881/Libtiff-Libtiff.html?vendor_id=2224. > > Unfortunately, the descriptions in the long list of CVEs are not always > clear as to if they are in the library, or the utilities, but the vast > majority appear to be in the utilities. This is clearly a flaw in the > CVE system which should have allocated separate CVE notices for libtiff, > and for the libtiff tools. > > Regardless, there is an excessive concern about use of "memory-unsafe" > languages when it comes to computer security. A great number of computer > security issues have nothing to do with memory safety. > > As regards to libtiff, the major concern is the TIFF format itself which > offers a wide variety of options (via tags, and the interpretation of > one or more TAGs at once), and it is not always clear how to do things > properly. C++ will not solve this problem unless it is user-facing and > assures correctness based on rigid design rather than interpretation. > > Using Rust as a base would incur much more significant issues than using > C++ as the base because the Rust run-times and toolchain are cumbersome > and only available for very limited targets. > > Bob > > > _______________________________________________ > Tiff mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/tiff >
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
