CVE-2024-3094 (aka "xz hackdoor") and GDAL and pyogrio's wheels

[jorisvandenbossche]

Also see GDAL's messsage about it: https://lists.osgeo.org/pipermail/gdal-dev/2024-March/058792.html

liblzma is included in our binary wheels through the vcpkg build of GDAL (although it should typically not be used through pyogrio usage, given GDAL only uses it for raster drivers AFAIK)>

But to be very explicit here: our wheels don't included the comprised versions.
Our last GDAL / vcpkg update was e6e6e42, and so that is from before the affected versions were released (the wheels currently being built main contain liblzma 5.4.4)

---

One consequence though is that our wheels building is failing right now, because github has taken down the repos, and so the vcpkg build script that tries to fetch those sources fails (microsoft/vcpkg#37839)

[brendan-ward]

Looks like we need to wait for at least GDAL 3.8.5 to land in vcpkg to update wheels because 3.8.4 coincides with the compromised version of liblzma and as far as I can tell the GDAL vcpkg port does not use a version constraint against liblzma that would force pulling in an older version. Also as far as I can tell, we shouldn't be pulling in liblzma at all because it is in the default-features for the GDAL port not the recommended-features set that we use.

According to the logs, it is indeed pulling in liblzma, so we definitely need to avoid pulling in the compromised versions.

(wheels are building again against the older liblzma version)

[jorisvandenbossche]

The github repo of xz was enabled again last night, so in general the vcpkg builds should work again. vcpkg already reverted the libzma port back to a non-compromised version, so using a recent vcpkg version should be fine for us. Although given GDAL just released 3.8.5, it would indeed be nice to wait until that is included in vcpkg and update our wheel build to have the latest GDAL.

[jorisvandenbossche]

Updating to GDAL 3.8.5 in #392