[gdal-dev] How to deal with security related bug reports?

[Greg Troxel]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210729/90d338d4/attachment.sig>