2008.08.29 22:53 "[Tiff] Some security fixes from RHEL", by Even Rouault

2008.08.31 21:59 "Re: [Tiff] Some security fixes from RHEL", by Lee Howard

Honestly, I think libtiff has lots of security issues in the fact of hostile TIFF files, and I find it hard to get excited about any particular issue.

If an application needs to be secure/stable in the face of hostile files then it should not link against libtiff.

While the above statements are undoubtedly accurate, the sentiments that they express are unhealthy for the large community that uses libtiff. So, while the statements may be true, they really should not so be.

Maintainers and developers of any software should be committed to the software development and to the health of the community that uses that software. Some degree of responsibility is expected. When flaws in the

software are discovered, be they rather benign or security-related, the community looks to developers and maintainers to take action. Failure to take action leads the community into an atmosphere of uncertainty and mistrust... all of which further inhibits the software development cycle.

Understand that while the software development process may be slow, stagnant, or distracted, distribution maintainers and application maintainers are under pressure from their own customers to be responsive and to indemnify any inaction by the upstream. Thus you will find RedHat, Fedora, SuSE, Debian, Gentoo, etc. maintainers who will have to patch and patch and continue to patch to satisfy those expectations.

It seems to me that the least that could be done in such situations would be to accept the patches developed downstream and to acknowledge and be at least verbally responsive to credible reports of such issues.

All that these statements say to the community is what is far too often heard in open-source circles: "If you don't like it, fix it yourself or go somewhere else. After all, it is open source."

Again, while such a statement may be accurate, neither is it healthy nor is it truly helpful.

Thanks,

Lee.