+Ellen Johnson who was the last MathWorks contact I see in my email history from tiff@
Ashish, Personal opinion follows... I suggest you work up some internal company documentation for maintaining your local copy of libtiff. The politics / churn of large businesses can be challenging. I maintain the local copy of libtiff inside of Google / Alphabet and I'm happy to chat about my strategy if that is helpful. It's basically: (apologies to all who have heard this all before :) 1. Don't include any of the parts of libtiff that we don't use. a. We only build tiffinfo, tiffsplit, and the library. b. The binaries are not included with any releases. They are only present for testing and debugging. c. Don't build any of the source files for parts not used like compression types d. Annotate which CVEs do not apply because we just don't have that part of the code in our code base. It's up to me to figure that out. 2. Update to upstream head with typically 1-2 week delay. a. Don't wait for point releases b. Be ready to work with upstream if you catch any regressions locally 3. Do tons of our own testing (for me this means run the tests for millions of test targets across the entire company) 4. Each team does their own integration tests for release of their binaries 5. Try not to keep local patches to the library. Send PRs for local fixes so that everyone can benefit. 6. Consider donating to tiff and/or the ecosystem around libtiff, e.g., Google has given money to the GDAL NumFocus fund and NumFocus in general for the last couple years and provides OSS Fuzz. 7. Have lots of monitoring of any issues that occur in deployed code 8. Make sure to deploy updated code at a regular cadence. See also these resources for help on the above: * https://abseil.io/resources/swe-book * https://sre.google/books/ -Kurt Engineer at Google, PSC member GDAL and PROJ. 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 On Mon, Aug 19, 2024 at 7:45 AM Greg Troxel via Tiff <[email protected]> wrote: > Ashish Patil via Tiff <[email protected]> writes: > > > This issue is of high priority for us, as our customers have started > > reporting it. We look forward to your prompt response regarding its > > status. > > You appear to misunderstand the nature of open source projects and this > comes across as very rude. > > Please talk to your management about assigning someone to look into > this, prepare and test a fix, and submit it. And also to have that > person stay on the mailing list, test betas and rcs, and generally be a > member of the community. > _______________________________________________ > Tiff mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/tiff >
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
