<div dir="ltr">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:<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>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.</div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>But, I'd definitely like to hear people with opposing views. </div><div><br></div><div>-kurt</div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 28, 2021 at 10:38 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">PSC,<br>
<br>
We just got <a href="https://github.com/OSGeo/gdal/issues/4146" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/issues/4146</a> from someone <br>
trying to get in touch with a security issue. How do we want to deal <br>
with that ? Personally dealing with all the secrecy about security <br>
issues is not super appealing and my natural inclination would be to <br>
deal with them as any other issue.<br>
<br>
An alternative, used by Mapserver, would be to setup a dedicated private <br>
github repository, where we would invite only users (but they are likely <br>
able to see all issues, not just theirs). Or perhaps just make a <br>
repository accessible to PSC / trusted developers, interact with the <br>
reporter through email (who wants to be in the email loop?) and paste <br>
there the report and updates, but that becomes cumbersome.<br>
<br>
Another point, assuming we have a private issue tracker, is, assuming <br>
the issue is confirmed and we have a fix for it, how do we deal with it <br>
? My inclination would be to just commit the fix (the issue would become <br>
more or less public once a candidate pull request is issued) and not <br>
issue a dedicated release, but use our regular bugfix releases.<br>
<br>
Thoughts ?<br>
<br>
Even<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>