CVE-2019-25050

Advisory

Gdal 3.4.0 includes a fix for its C dependency 'netcdf': A stack read overflow vulnerability.
https://github.com/OSGeo/gdal/commit/eec259c7c73f8bc200ff41efc8e6771472b48f86
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39189

Affected package

Affected versions

Fixed versions

Vulnerability changelog

a) cd swig/python/gdal-utils

b) python setup.py bdist_wheel

c) Check the output:
twine check dist/gdal_utils-*.whl

c) For trial :
twine upload dist/gdal_utils-*.whl -r pypitest

d) For real :
twine upload dist/gdal_utils-*.whl

16) Build and bundle the java bindings.

a) cd swig/java

b) Make any updates to java.opt that might be required for the platform. For
example osx and windows users will have to change JAVA_INCLUDE to contain
include/darwin and include/win32 respectively.

c) Build the bindings:

make

17) Build maven artifacts. NOTE: This step only works on Linux and OSX since it
requires a shell script to build javadocs.

A quick one-liner for this step is:

ant maven_sign -Dgpg.key=... -Dgpg.pass=...

This will build and sign the artifacts with a single command. Read on for
more details.

a) Build the maven artifacts:

ant maven

Upon success maven artifacts should be located in the build/maven directory.

b) Sign maven artifacts with GPG. This step is required in order to deploy the
maven artifacts to the central Maven repository. Before this step can
proceed you must set up a signing key as described here:

http://central.sonatype.org/pages/working-with-pgp-signatures.html

Each developer can use their own signing key although it is usually best to
avoid constantly using a different key for releases as users will need to
import the public key in order to verify the artifacts.

Here are a quick set of steps to generate a signing key key.

gpg --gen-key
gpg --list-keys (and note the key id)
gpg --keyserver hkp://pool.sks-keyservers.net --send-keys <key id>

See the above link for more details.

Once a key is set up run the "maven_sign" ant target. The target takes two
parameters specified as system properties:

1. gpg.key - The identifier for the signing key
2. gpg.pass - The passphrase for the signing key (optional)

ant maven_sign -Dgpg.key=... -Dgpg.pass=...

Upon success you should see maven artifacts along with generated signatures
in the build/maven directory. You will also find a file named "bundle.jar"
that contains all the maven artifacts with signatures. This file is what
will be uploaded to maven central. See the next step.

18) Deploy maven artifacts to Maven central.

NOTE: Before you can deploy to maven central you must set up an account
in Sonatype JIRA. That can be done here:

https://issues.sonatype.org/secure/Signup!default.jspa

Once you have an account set up you must be associated with the gdal
project. Create a ticket here asking to be associated with the project:

https://issues.sonatype.org/browse/OSSRH

The entire deployment process is described in detail here:

http://central.sonatype.org/pages/manual-staging-bundle-creation-and-deployment.html
http://central.sonatype.org/pages/releasing-the-deployment.html

The following steps summarize the process.

a) Log into the Sonatype repository manager at https://oss.sonatype.org. Use the
same credentials as your Sonatype JIRA account.

b) Once log in select "Staging Upload" on the left hand side.

c) Select "Artifact Bundle" under "Upload Mode" and then choose the "bundle.jar"
created in the previous Step 22. Finally "Upload Bundle" to start the upload.

d) When the upload has been completed you will be notified that a staging
repository has been created. Note the name of the repository. It should look
something like "orggdal-100x".

e) From the left hand menu navigate to "Staging Repositories". In the search
box look for the staging repository name you noted from the previous section.
Or just search for "gdal". It should be obvious which repository is the
current one.

f) Select the staging repository. If all is well You should see the option to
"Release" (Located as a button near the top of the page). If not it means
there was an issue with the bundle. Consult the "Activity" tab at the bottom
of the page to find out why.

e) Click the "Release" button and that is it! The release should be available in
Maven Central shortly. You can verify this by going to search.maven.org and
searching for "gdal".

19) Create a release on GitHub
Go to https://github.com/OSGeo/gdal/releases/new
And create a release for the vX.Y.Z tag
Attach the gdal-X.Y.Z.tar.gz, gdal-X.Y.Z.tar.gz.md5, gdalXYZ.zip, gdalXYZ.zip.md5 and gdalautotest-X.Y.Z.zip files

20) Regenerate Docker images

e.g
./docker/build-all.sh --with-multi-arch --release --tag 3.3.1 --gdal v3.3.1 --proj 8.1.0 --platform linux/arm64,linux/amd64 --push

and update docker/README.md with the latest release

21) Announce release to :
- major release: gdal-devlists.osgeo.org, gdal-announcelists.osgeo.org, news_itemosgeo.org.
- bugfix release: gdal-devlists.osgeo.org, gdal-announcelists.osgeo.org

Example:
- bugfix release: https://lists.osgeo.org/pipermail/gdal-dev/2019-July/050543.html
- feature release: https://lists.osgeo.org/pipermail/gdal-dev/2020-May/052117.html

Note: gdal-announce is moderated. Make sure that your email address is approved
('mod' tick disabled in https://lists.osgeo.org/mailman/admin/gdal-announce/members),
or your message manually approved, with an administrator of the list.



= GDAL/OGR 3.3.0 Release Notes

== In a nutshell... ==

* RFC 77 (https://gdal.org/development/rfc/rfc77_drop_python2_support.html): Drop Python 2 support in favor of Python 3.6 (#3142)
* RFC 78 (https://gdal.org/development/rfc/rfc78_gdal_utils_package.html): Add a gdal-utils Python package
* New driver:
- STACTA: raster driver to read Spatio-Temporal Asset Catalog Tiled Assets
* Add /vsiadls/ virtual file system for Azure Data Lake Storage Gen2
* Improved drivers: DIMAP, NITF
* Number of improvements in Python bindings
* Add automatic loading of configuration options from a file
* Add support for enumerated, constraint and glob field domains in MEM, FileGDB/OpenFileGDB and GeoPackage drivers
* Deprecation:
- Disable by default raster drivers DODS, JPEG2000(Jasper), JPEGLS, MG4LIDAR, FUJIBAS, IDA, INGR, ZMAP and vector driver ARCGEN, ArcObjects, CLOUDANT, COUCHDB, DB2, DODS, FME, GEOMEDIA, GTM, INGRES, MONGODB, REC, WALK at runtime, unless the GDAL_ENABLE_DEPRECATED_DRIVER_{drivername} configuration option is set to YES. Those drivers are planned for removal in GDAL 3.5
- Perl bindings are deprecated. Removal planned for GDAL 3.5. Use Geo::GDAL::FFI instead
* Removal of BNA, AeronavFAA, HTF, OpenAir, SEGUKOOA, SEGY, SUA, XPlane, BPG, E00GRID, EPSILON, IGNFHeightASCIIGrid, NTV1 drivers. Moved to (unsupported) https://github.com/OSGeo/gdal-extra-drivers repository.
* Continued code linting (cppcheck, CoverityScan, etc.)
* Bump of shared lib major version

== Backward compatibility issues ==

See MIGRATION_GUIDE.txt

== GDAL/OGR 3.3.0 - General Changes ==

General:
* fix build with recent gcc/clang

Build(Unix):
* Support CharLS 2.1 on Debian as well. (3083)
* disable LERC on big-endian hosts, as it is not big-endian ready
* gdal-config (non installed): add -I/gnm in CFLAGS
* fix compilation failure with gcc < 5 in Elasticsearch driver
* configure: Also save LDFLAGS when checking compatibility.
* configure: Ensure --with-geos/sfcgal fail if unavailable.
* configure: check presence of linux/fs.h for Linux builds
* configure: Fix gdal compilation when using proj-8.0.0 and libtiff with static jpeg support
* GDALmake.opt.in: in non-libtool LD_SHARED builds, do not link applications against libgdal dependencies, but only against libgdal itself

Build(Windows):
* add missing makefile.vc for heif

Resources

• https://pypi.org/project/gdal
• https://pyup.io/changelogs/gdal/
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-25050