On Wed, Dec 15, 2021, 15:40 William Kenworthy <bi...@iinet.net.au> wrote:
> I was reading up on log4j and its recent problems and discovered it can
> "hide" layers deep inside java jar files depending on how its used.
>
> I can see that dev-embedded/arduino includes log4j directly (and does it
> embed log4j in code produced for IoT?):
>
> rattus ~ # locate *.jar|grep 4j
> /usr/share/arduino/lib/log4j-api-2.12.0.jar
> /usr/share/arduino/lib/log4j-core-2.12.0.jar
> /usr/share/arduino/lib/slf4j-api-1.7.22.jar
> /usr/share/arduino/lib/slf4j-simple-1.7.22.jar
> rattus ~ #
>
> BUT there are a lot of other jar files on my systems which have log4j
> embedded in it.
>
These are likely coming in as transitive dependencies from other
dependencies that might be shaded. Any dependencies pulling log4j need to
updated. Easier said than done obviously.
> Sylf (not in portage that I can see) seems like it can build an SBOM for a
> target (Software Bill of Materials) that could identify deeply embedded
> log4j instances - has anyone used this on a gentoo system (it looks like it
> needs to specifically target a distro) or is there something
> easier/better? "strings|grep log4j" works on the arduino jar files but
> that wont work on propriety encrytpted jar files (such as propriety apps
> where it may likely be used). And is doing just jar files enough?
>
> BillK
>
> ** try something like 'find /opt /lib64 /usr/share -name *.jar -print
> -exec strings {} \; |grep log4j'
>
