<div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif">Even, </div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">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). </div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">Best regards,</div><div class="gmail_default" style="font-family:arial,sans-serif">Frank</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 28, 2021 at 3:36 PM Kurt Schwehr <<a href="mailto:schwehr@gmail.com">schwehr@gmail.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"><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:0px 0px 0px 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" target="_blank">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>
_______________________________________________<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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font face="monospace">---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>light and sound - activate the windows | +1 650-701-7823<br>and watch the world go round - Rush | Geospatial Software Developer</font></div></div></div></div></div>