Agreed. Unfortunately, we're looking for a quick solution to a customer
complaint. I'll ponder it some more.
On Wed, Jul 28, 2021 at 12:28 PM Even Rouault
wrote:
> Simon,
>
> I don't think that killing a thread is a safe practice in general. It
> would likely result in memory leaks and maybe in
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
I'm working with SPOT 6 and 7 imagery delivered in DIMAP format. I've figured
out how to extract the multispectral and pan-chromatic bands into geotiff with
gdal-translate so they're easier to work with.
((cross posted to
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
Simon,
I don't think that killing a thread is a safe practice in general. It
would likely result in memory leaks and maybe in some other inconsistent
state that could crash the whole process. An interesting enhancement
for such cases would be to be able to provide a progress / abort
Dear All,
I am aware that some improvements were made in the 2.3 timeframe with
regards to dealing with large GeoJSON files, although even in 3.2, it's
still very slow and memory hungry.
Our system allows for aborting imports, but this only works reliably once
it has actually got to the stage of
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
Louis-Phillippe,
this sounds like a bug. Please file a ticket at
https://github.com/OSGeo/gdal/issues/new with all the below details
Even
Le 28/07/2021 à 17:08, Rousseau Lambert,Louis-Philippe (ECCC) a écrit :
Hi,
I'm trying to read a projection in proj4 string from a NetCDF and gdal
/
Hi,
I'm trying to read a projection in proj4 string from a NetCDF and gdal /
proj fails to recognize the /*conversion method: Polar_Stereographic*/.
The issue appears with any files in:
https://dd.weather.gc.ca/model_riops/netcdf/forecast/polar_stereographic/2d/06/003/
example gdalinfo
Matvei,
Hard to say if the use of json-c 0.11 by GDAL trigger those
vulnerabilities, but you should assume they might be hit. I've filed
https://github.com/OSGeo/gdal/issues/4143 about that.
But you should be able to build GDAL any external recent json-c. The
internal copy has mostly
Hello! I am new to the list, I hope that this is the right place to ask.
GDAL's geojson driver uses libjson, which is a fork of json-c 0.11. There have
been a couple security vulnerabilities patched in json-c since version 0.11.
These vulnerabilities are:
- CVE-2013-6370 (buffer overflow if
11 matches
Mail list logo
