2018.04.09 07:29 "[Tiff] fuzzing libtiff with google's oss-fuzz", by Paul Kehrer

2018.04.09 14:09 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Even Rouault

On lundi 9 avril 2018 08:44:02 CEST Bob Friesenhahn wrote:

If sufficient libtiff maintainer time/energy is not immediately available then enrolling in oss-fuzz will result in a great many issues being reported in libtiff and exposed to public view (along with files to cause the problem) which are not yet fixed. This would be harmful to users. There has to be enough volunteer maintainer time/energy to get issues resolved and into a libtiff release in 90 days time. Actually, after a problem is fixed in the Git repository, the issue is made public in just 30 days so there needs to be many releases in order to ensure that there is a release before the issues are made public.

Bob,

I somehow understand your position on it, but you are probably assigning you more responsability than you should. On our volunteer time, we have no moral or whatsoever obligations regarding anyone to fix any issues. For that reason, I'm less and less willing to treat with privately reported issues.

Black hat hackers can already use oss-fuzz infrastructure locally (this is how you set up oss-fuzz initially by the way) to find issues, so we can assume that vulnerabilities are already known by them, this way or another. Having them publicly reported through oss-fuzz is better I think.

I don't think it really matters if bugs are not fixed in the 90 day delay. If they matter to people, they will look at the public issues and try to fix them and issue pull requests. Or fund people to fix them.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com