<div dir="ltr"><div>Thank you for the analysis, Even!</div><div><br></div><div>I've made similar announcements for the fiona and rasterio projects and plagiarized your subject line. Fiona and rasterio wheels on PyPI include versions of liblzma no more recent than 5.4.4 and do not include libarchive.<br></div><div><br></div><div><a href="https://github.com/Toblerity/Fiona/discussions/1367">https://github.com/Toblerity/Fiona/discussions/1367</a></div><div><a href="https://github.com/rasterio/rasterio/discussions/3047">https://github.com/rasterio/rasterio/discussions/3047</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 30, 2024 at 1:16 PM Even Rouault via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</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"><u></u>

  

    
  
  <div>
    <p>Hi,</p>
    <p>TLDR: no specific reason to worry.</p>
    <p>My longer analysis:<br>
    </p>
    <p>Those following the recent security news have certainly come
      across <a href="https://lwn.net/Articles/967180" target="_blank">https://lwn.net/Articles/967180</a> or similar articles, and if
      you don't have and have been running a cutting edge Linux
      distribution recently, you *should* follow related security alerts
      emitted by your vendor.</p>
    <p>liblzma (the library part of the xz software distribution) is an
      optional libtiff dependency for the TIFF LZMA codec, and an
      optional direct GDAL dependency since GDAL 1.8.0. Initially only
      used when building GDAL with its internal libtiff, and since GDAL
      3.4.0, directly too as a Zarr codec.<br>
    </p>
    <p>Beyond activity in liblzma / xz being potentially suspicious with
      at least 2 years of "contributions" by malicious actor
      <a href="https://github.com/JiaT75" target="_blank">https://github.com/JiaT75</a><span>, which makes
        the current headlines, it has also been found that they
        contributed to libarchive too since 2021
        (<a href="https://github.com/libarchive/libarchive/commits?author=JiaT75" target="_blank">https://github.com/libarchive/libarchive/commits?author=JiaT75</a>),
        and their latest commit
        <a href="https://github.com/libarchive/libarchive/pull/1609" target="_blank">https://github.com/libarchive/libarchive/pull/1609</a> is in
        particular pointed as suspicious. As far as I can see, this
        commit is present in libarchive >= 3.6. I mention libarchive
        because it is an optional GDAL dependency since GDAL 3.7.0 for
        the /vsi7z/ and /vsirar/ virtual file systems. <br>
      </span></p>
    <p><span>We don't have vendored copies of
        liblzma or libarchive in the GDAL source code repository.<br>
      </span></p>
    <p>Regarding GDAL Docker images, here's the status of versions they
      ship:<br>
    </p>
    <p>- <a href="http://ghcr.io/osgeo/gdal:alpine-small-3.8.4" target="_blank">ghcr.io/osgeo/gdal:alpine-small-3.8.4</a> and
      <a href="http://ghcr.io/osgeo/gdal:alpine-normal-3.8.4" target="_blank">ghcr.io/osgeo/gdal:alpine-normal-3.8.4</a>:<br>
      xz-libs-5.4.3-r0 <br>
      libarchive-3.7.2-r0<br>
    </p>
    <p>- <a href="http://ghcr.io/osgeo/gdal:ubuntu-full-3.8.4" target="_blank">ghcr.io/osgeo/gdal:ubuntu-full-3.8.4</a>:<br>
      liblzma5:amd64                5.2.5-2ubuntu1    <br>
      libarchive13:amd64            3.6.0-1ubuntu1<br>
    </p>
    <p>- <a href="http://ghcr.io/osgeo/gdal:ubuntu-small-3.8.4" target="_blank">ghcr.io/osgeo/gdal:ubuntu-small-3.8.4</a>:<br>
      liblzma5:amd64              5.2.5-2ubuntu1<br>
    </p>
    <p>So those liblzma versions are not currently considered as
      affected. Regarding libarchive status and the impact of JiaT75's
      activity there, it seems to me we are yet in undecided territory
      and it wouldn't be surprising to see update of those libraries in
      the coming weeks, as exploration of past activity from that
      compromising entity is performed.<br>
    </p>
    <p>It is a good time to recall usual general best-practices:<br>
    </p>
    <p>- avoid opening datasets coming from unknown or untrusted sources<br>
    </p>
    <p>- if you do so, prefer doing that on dedicated workstations that
      don't have access to sensitive information<br>
    </p>
    <p>- you may reduce your potential exposure by disabling at build
      time optional dependencies you don't need.</p>
    <p>Even<br>
    </p>
    <pre cols="72">-- 
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </div>
</blockquote></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Sean Gillies</div></div>