From the semi-outside, and packaging perspective, I can completely understand not having a full-blown private security process. It's certainly a lot of work.
Some upstream packages have private reporting paths, and develop and test patches in secret, even including packagers. I have several times tested patches and had them staged to update pkgsrc after an embargo time is passed. However, this is a huge extra amount of effort and indeed nobody is showing up wanting this and writing checks. I think the earlier disclaimer is a bit much. I think it's perfectly adequate to say that there's no special or private mechanism for security problems. As for creating point releases after a security bugfix, I'd say there's no need to say if you will or you won't but if there's a bug that leads to code execution from bad input, it's probably best to snap a micro from the release branch, and with any luck that will be quite infrequent. It also seems clear that any program whose point it is to read a vast number of formats is going to have issues at a rate proportional to number of formats, to first order, so it might be useful to point out for those that don't realize that: The purpose of GDAL is to read and write a very large number of data formats, and many of these are complex. Therefore one should expect that errors exist in some of this code, including errors with security implications. or something, to make the point without saying "we know it's terrible", as my impression is that there isn't a huge rate of bug reports or a big pile of open security bugs. Really pretty much any program needs to be used with suspicion, including things that process web content or images, etc. So in summary I think the proposed approach is fine. greg
signature.asc
Description: PGP signature
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
