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

[Kurt Schwehr]

My take is pretty much the same as Even's.  I suggest that we add a
SECURITY.md that says we do not currently treat security bugs in gdal
privately and that we don't generally do specific releases for security
issues.   I thought there used to be a statement somewhere in the files
that said that the code should not be considered secure / safe.  I think we
should bring something like that back that says something along the lines
of:

Some effort is made to ensure the code is safe, but analysis tools like
ossfuzz continually find issues in the code.  Data from untrusted sources
should be treated with caution.  When security is a major concern, consider
running GDAL or code using GDAL in a restricted sandbox environment.   If
someone wants to specifically fund a security effort, then we can consider
doing something more.


I'm one of those running gdal in a space where security is a huge issue.
We (Google) have GDAL running in a very restricted sandbox for any
untrusted data.

But, I'd definitely like to hear people with opposing views.

-kurt

On Wed, Jul 28, 2021 at 10:38 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> PSC,
>
> We just got https://github.com/OSGeo/gdal/issues/4146 from someone
> trying to get in touch with a security issue. How do we want to deal
> with that ? Personally dealing with all the secrecy about security
> issues is not super appealing and my natural inclination would be to
> deal with them as any other issue.
>
> An alternative, used by Mapserver, would be to setup a dedicated private
> github repository, where we would invite only users (but they are likely
> able to see all issues, not just theirs). Or perhaps just make a
> repository accessible to PSC / trusted developers, interact with the
> reporter through email (who wants to be in the email loop?) and paste
> there the report and updates, but that becomes cumbersome.
>
> Another point, assuming we have a private issue tracker, is, assuming
> the issue is confirmed and we have a fix for it, how do we deal with it
> ? My inclination would be to just commit the fix (the issue would become
> more or less public once a candidate pull request is issued) and not
> issue a dedicated release, but use our regular bugfix releases.
>
> Thoughts ?
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210728/5df76ae8/attachment-0001.html>