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

[Frank Warmerdam]

Even,

I agree with you and Kurt that we should try to avoid the overhead of
special security handling.  MapServer is intended to be web facing.  GDAL
is not.  That said, we should attempt to resolve security issues in the
normal course of bug fixing and releases.  If there is a strong case for a
different approach, hopefully it will be made by folks willing to pay for
the extra work (through sponsorship or other contributions).

Best regards,
Frank


On Wed, Jul 28, 2021 at 3:36 PM Kurt Schwehr <schwehr at gmail.com> wrote:

> 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
>>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>


-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | +1 650-701-7823
and watch the world go round - Rush    | Geospatial Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210728/476db9db/attachment.html>