Re: [gdal-dev] Large GeoJSONs and aborting file opening

2021-07-28 Thread Simon Eves 
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 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 callback.
>
> Even
> Le 28/07/2021 à 21:22, Simon Eves a écrit :
>
> 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 reading features from the file. With
> the GeoJSON, it just sits in the GDALOpenEx call for ages.
>
> My question, therefore, is whether it might be practical to run the
> GDALOpenEx in a separate thread with a future to return the resulting
> handle, such that it could be monitored and killed if necessary?
>
> Mainly I would be concerned that killing the thread might trash some
> global GDAL state that might then not be recoverable, or that the open
> relies on some TLS for the process thread and therefore might not work
> properly.
>
> We're going to try it anyway, but opinions welcomed, thanks!
>
> Simon
>
> --
> 
> Simon Eves
> Senior Graphics Engineer, Rendering Group
> 100 Montgomery St (5th Floor), San Francisco, CA 94104, USA
>
>
> Email: simon.e...@omnisci.com | Cell:  +1 (415) 902-1996
>
>
> ___
> gdal-dev mailing 
> listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>

-- 

Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA


Email: simon.e...@omnisci.com | Cell:  +1 (415) 902-1996
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

2021-07-28 Thread 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  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 
> 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@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>


-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | +1 650-701-7823
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Making use of SPOT imagery mask files

2021-07-28 Thread Matt.Wilkie 
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 
https://gis.stackexchange.com/questions/405077/making-use-of-spot-imagery-mask-files))

In each archive there are a series of mask files in 
gml format, which I can 
read with ogrinfo and Qgis. However the mask files don't have a coordinate 
system so I can't use them with the images.

>From the ogrinfo report it appears the GML are using image row and column 
>pixel dimensions. (The matching source image is 9652 x 57083.)

$ ogrinfo \SPOT6_sample_roi.gml maskfeature

INFO: Open of `\SPOT6_sample_roi.gml'

  using driver `GML' successful.

Metadata:

  NAME=Area of interest mask for product id 
SPOT6_MS_201308032015087_SEN_SPOT6_20160316_1601281mdxzlrvssw12_1



Layer name: MaskFeature

Geometry: Polygon

Feature Count: 1

Extent: (1.00, 1.00) - (9653.00, 57084.00)

Layer SRS WKT:

(unknown)

gml_id: String (0.0) NOT NULL

maskType: String (18.0)

OGRFeature(MaskFeature):0

  gml_id (String) = REGION_OF_INTEREST-0

  maskType (String) = REGION_OF_INTEREST

  POLYGON ((9645.1767578125 6.41328716278076,9645.162109375 
5.32240867614746,9645.03125 4.30024194717407,9644.7841796875 
3.2741334438324,9644.5390625 2.39344930648804,9644.181640625 
1.72693908214569,9643.7666015625 1.20388793945312,9643.4931640625 
1.0,8939.99609375 1.0,1.0 4.3671669960022,1.0 28542.5,1 57084,9653 57084,9653.0 
45960.265625,9645.1767578125 6.41328716278076))

The gdalinfo report for the source 
image also 
shows pixel coordinates for the coordinate system:

Corner Coordinates:

Upper Left  (0.0,0.0)

Lower Left  (0.0,57083.0)

Upper Right ( 9652.0,0.0)

Lower Right ( 9652.0,57083.0)

Center  ( 4826.0,28541.5)

However it also has RPC metadata that seems to be enough to have Qgis and 
ArcMap/Pro display it in the right geographical location:

RPC Metadata:

  HEIGHT_OFF=500.0

  HEIGHT_SCALE=500.0

  LAT_OFF=64.90742355

  LAT_SCALE=1.71583845

  ...snip...

  SAMP_OFF=4825

  SAMP_SCALE=4826.0

Sample files at 
https://drive.google.com/drive/folders/119QEECJ42FKt0A9mq55rRmGsT9-5nSZq?usp=sharing
 (The image has been resized to 10% of it's original size.)

How might I marry the raster coordinate system info to the mask files so I can 
use them together?
Thanks in advance for your time and thoughts,

Matt Wilkie
A / Manager
(Geomatics Developer & Administrator)
Environment | Technology, Innovation and Mapping
T 867-667-8133 | Yukon.ca
Hours: 08:30-16:30, Mon-Wed: Office, Thu: Remote, Fri: Away.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

2021-07-28 Thread 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 
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@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Large GeoJSONs and aborting file opening

2021-07-28 Thread Even Rouault 

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 callback.


Even

Le 28/07/2021 à 21:22, Simon Eves a écrit :

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 reading features from the 
file. With the GeoJSON, it just sits in the GDALOpenEx call for ages.


My question, therefore, is whether it might be practical to run the 
GDALOpenEx in a separate thread with a future to return the resulting 
handle, such that it could be monitored and killed if necessary?


Mainly I would be concerned that killing the thread might trash some 
global GDAL state that might then not be recoverable, or that the open 
relies on some TLS for the process thread and therefore might not work 
properly.


We're going to try it anyway, but opinions welcomed, thanks!

Simon

--


Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA



Email: simon.e...@omnisci.com  | Cell: 
+1 (415) 902-1996





___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Large GeoJSONs and aborting file opening

2021-07-28 Thread Simon Eves 
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 reading features from the file. With
the GeoJSON, it just sits in the GDALOpenEx call for ages.

My question, therefore, is whether it might be practical to run the
GDALOpenEx in a separate thread with a future to return the resulting
handle, such that it could be monitored and killed if necessary?

Mainly I would be concerned that killing the thread might trash some global
GDAL state that might then not be recoverable, or that the open relies on
some TLS for the process thread and therefore might not work properly.

We're going to try it anyway, but opinions welcomed, thanks!

Simon

-- 

Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA


Email: simon.e...@omnisci.com | Cell:  +1 (415) 902-1996
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

2021-07-28 Thread Even Rouault 

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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL fails to read projection with: Unsupported conversion method: Polar_Stereographic

2021-07-28 Thread Even Rouault 

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 
/ 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 request:

/$ gdalinfo -proj4 input.nc//
//Driver: netCDF/Network Common Data Format//
//...//
//*ERROR 1: PROJ: proj_as_proj_string: Unsupported conversion method: 
Polar_Stereographic*//*

*//*PROJ.4 string is:*//*
*//*''*//
//Origin = (-2500.000,8047500.000)//
//Pixel Size = (5000.000,-5000.000)//
//...//
//  SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 
84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AXIS["Latitude",NORTH],AXIS["Longitude",EAST],AUTHORITY["EPSG","4326"]]//

//  X_BAND=1//
//  X_DATASET=NETCDF:"dd_riops.nc":longitude//
//  Y_BAND=1//
//  Y_DATASET=NETCDF:"dd_riops.nc":latitude//
//Corner Coordinates://
//Upper Left  (   -2500.000, 8047500.000)//
//Lower Left  (   -2500.000,   -2500.000)//
//Upper Right ( 8847500.000, 8047500.000)//
//Lower Right ( 8847500.000,   -2500.000)//
//Center  ( 4422500.000, 4022500.000)//
//.../

The gdal version I'm getting the error with: GDAL 3.1.3, and PROJ 
version: Rel. 7.2.0.


I know this command previsously worked fine, using gdal GDAL 2.4.4 and 
proj Rel. 4.8.0 and I was able to get the PROJ4 string: '+proj=stere 
+lat_0=90 +lat_ts=59.3768695209 +lon_0=-100 +k=0.93301243 
+x_0=4245000 +y_0=5295000 +a=6371229 +b=6371229 +units=m +no_defs '


Also, if I try to reproject the file in EPSG:4326 with a gdalwarp 
(GDAL 3.1.3) command, it fails, because it does not read the source 
srs, but if I specify it using the -s_srs flag it works fine, example:


|gdalwarp -of NetCDF -s_srs "+proj=stere +lat_0=90 
+lat_ts=59.3768695209 +lon_0=-100 +x_0=4245000 +y_0=5295000 
+R=6371229 +units=m +no_defs" -t_srs EPSG:4326 input.nc output.nc|


Is this a bug in gdal / proj, or a parameter in the projection 
definition that is not supported anymore ?


Thanks

LP

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL fails to read projection with: Unsupported conversion method: Polar_Stereographic

2021-07-28 Thread Rousseau Lambert,Louis-Philippe (ECCC) 

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 request:

/$ gdalinfo -proj4 input.nc//
//Driver: netCDF/Network Common Data Format//
//...//
//*ERROR 1: PROJ: proj_as_proj_string: Unsupported conversion method: 
Polar_Stereographic*//*

*//*PROJ.4 string is:*//*
*//*''*//
//Origin = (-2500.000,8047500.000)//
//Pixel Size = (5000.000,-5000.000)//
//...//
//  SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 
84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AXIS["Latitude",NORTH],AXIS["Longitude",EAST],AUTHORITY["EPSG","4326"]]//

//  X_BAND=1//
//  X_DATASET=NETCDF:"dd_riops.nc":longitude//
//  Y_BAND=1//
//  Y_DATASET=NETCDF:"dd_riops.nc":latitude//
//Corner Coordinates://
//Upper Left  (   -2500.000, 8047500.000)//
//Lower Left  (   -2500.000,   -2500.000)//
//Upper Right ( 8847500.000, 8047500.000)//
//Lower Right ( 8847500.000,   -2500.000)//
//Center  ( 4422500.000, 4022500.000)//
//.../

The gdal version I'm getting the error with: GDAL 3.1.3, and PROJ 
version: Rel. 7.2.0.


I know this command previsously worked fine, using gdal GDAL 2.4.4 and 
proj Rel. 4.8.0 and I was able to get the PROJ4 string: '+proj=stere 
+lat_0=90 +lat_ts=59.3768695209 +lon_0=-100 +k=0.93301243 
+x_0=4245000 +y_0=5295000 +a=6371229 +b=6371229 +units=m +no_defs '


Also, if I try to reproject the file in EPSG:4326 with a gdalwarp (GDAL 
3.1.3) command, it fails, because it does not read the source srs, but 
if I specify it using the -s_srs flag it works fine, example:


|gdalwarp -of NetCDF -s_srs "+proj=stere +lat_0=90 
+lat_ts=59.3768695209 +lon_0=-100 +x_0=4245000 +y_0=5295000 
+R=6371229 +units=m +no_defs" -t_srs EPSG:4326 input.nc output.nc|


Is this a bug in gdal / proj, or a parameter in the projection 
definition that is not supported anymore ?


Thanks

LP
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Are ogr_geojson/libjson vulnerable to json-c CVEs?

2021-07-28 Thread Even Rouault 

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 changes to please our compiler warning changes, 
nothing significant.


Even

Le 28/07/2021 à 09:28, Matvei Stefarov via gdal-dev a écrit :

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 size_t is larger than int)
- CVE-2013-6371 (hash collision denial of service)
- CVE-2020-12762 (integer overflow and out-of-bounds write via a large JSON 
file)

The first two were patched in 0.12 by 
https://github.com/json-c/json-c/commit/64e36901a0614bf64a19bc3396469c66dcd0b015,
 and the last was patched by 
https://github.com/json-c/json-c/commit/31243e4d1204ef78be34b0fcae73221eee6b83be.
 I don't see similar changes applied to GDAL's fork of libjson, so it might 
still be vulnerable.

I discovered this potential problem because my GDAL-based software was flagged 
as vulnerable by static analysis tools 
(https://www.synopsys.com/software-integrity/security-testing/software-composition-analysis.html).
  This tool works likely detected the presence of 
json_c_version/json_c_version_num functions, which currently return 0.11.

So my questions are:
- Does GDAL appear to be vulnerable to these CVEs out-of-the-box?
- Would it be practical to build GDAL against a newer version of json-c instead 
of the bundled libjson -- or are there significant modifications in the fork?

Cheers,
Matvei Stefarov

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Are ogr_geojson/libjson vulnerable to json-c CVEs?

2021-07-28 Thread Matvei Stefarov via gdal-dev 
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 size_t is larger than int)
- CVE-2013-6371 (hash collision denial of service)
- CVE-2020-12762 (integer overflow and out-of-bounds write via a large JSON 
file)

The first two were patched in 0.12 by 
https://github.com/json-c/json-c/commit/64e36901a0614bf64a19bc3396469c66dcd0b015,
 and the last was patched by 
https://github.com/json-c/json-c/commit/31243e4d1204ef78be34b0fcae73221eee6b83be.
 I don't see similar changes applied to GDAL's fork of libjson, so it might 
still be vulnerable.

I discovered this potential problem because my GDAL-based software was flagged 
as vulnerable by static analysis tools 
(https://www.synopsys.com/software-integrity/security-testing/software-composition-analysis.html).
  This tool works likely detected the presence of 
json_c_version/json_c_version_num functions, which currently return 0.11.

So my questions are:
- Does GDAL appear to be vulnerable to these CVEs out-of-the-box?
- Would it be practical to build GDAL against a newer version of json-c instead 
of the bundled libjson -- or are there significant modifications in the fork?

Cheers,
Matvei Stefarov

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev