goodoldpaul@autistici.org writes:

> Hi Marius and Ludo,
> I managed to remove all vendored libraries except for glad.h which seems 
> to be some kind of generated glue code for loading OpenGL 
> (https://github.com/Dav1dde/glad). In the next two patches I'm adding 
> libtcod and it's dependency lodepng.

Excellent, thanks for taking the time to get rid of the bundled
dependencies.

> Guix lint is warning me that lodepng could be affected by 
> CVE-2019-17178, but taking a look at 
> https://nvd.nist.gov/vuln/detail/CVE-2019-17178 and 
> https://nvd.nist.gov/vuln/search/results?adv_search=true&cpe_version=cpe%3a%2fa%3alodev%3alodepng%3a2019-09-28 
> seems to indicate that lodepng should  be *not* vulnerable since 
> 28/09/2019, did I understand correctly?
>
> Please don't hesitate and tell me if anything should done w.r.t. the 
> CVE.

The CVE entry points to this commit:

https://github.com/FreeRDP/FreeRDP/commit/9fee4ae076b1ec97b97efb79ece08d1dab4df29a

Which changes something in FreeRDP's bundled version of LodePNG.  The
changes in question do not seem to be in upstream LodePNG:

https://github.com/lvandeve/lodepng/blob/master/lodepng.cpp#L1079

It's not clear to me whether this is a problem with LodePNG, or just
improper use of its API.  It looks like the latter: tree->lengths is
checked just below the changed line, so FreeRDP must be catching the
83 return code and keep going to get the memory leak described in the
CVE entry.

We can either ignore it using the 'lint-hidden-cve' property, and add a
comment that this version of LodePNG should not be used with FreeRDP; or
take the patch from FreeRDP, as it looks innocent enough.  I don't
really have a strong opinion here, nor sufficient expertise, so I'd be
happy if others could chime in.