Unable to resolve property ... ${cuda.version}-SNAPSHOT

[jacobfriedman]

What happened:

Libnnvp's ${cuda.version}-SNAPSHOT causes syft to timeout

https://github.com/tpn/cuda-samples/blob/4502d27f121a43662b737231fbc4b16462281f22/v12.0/libnvvp/features/com.nvidia.viper.feature_12.0.0.202211100455/META-INF/maven/com.nvidia.viper/com.nvidia.viper.feature/pom.xml#L8

error resolving maven property error=unable to resolve property: propertyValue=${cuda.version}-SNAPSHOT

What you expected to happen:

Syft should have either passed-over & warned-of/reported the resolution failure

Steps to reproduce the issue:

Crawl the above pom.xml

Anything else we need to know?:

Environment: u22 debian

• Output of syft version: latest
• OS (e.g: cat /etc/os-release or similar): arm64

[kzantow]

Hi @jacobfriedman, could you provide the steps you used to reproduce this? directory scan? direct file scan of the pom.xml?

[jacobfriedman]

Yep, directory scan.

[willmurphyscode]

Thanks for the report! I'm adding some quick steps to reproduce the issue:

wget https://github.com/tpn/cuda-samples/raw/4502d27f121a43662b737231fbc4b16462281f22/v12.0/libnvvp/features/com.nvidia.viper.feature_12.0.0.202211100455/META-INF/maven/com.nvidia.viper/com.nvidia.viper.feature/pom.xml
syft dir:.

On my machine this fails with a stack size exceeded error from the go runtime.

[jacobfriedman]

That's the same result @willmurphyscode

[willmurphyscode]

Thanks @jacobfriedman! Syft has code that tries to resolve variables in pom.xml files. My guess is that here, because the parent version and the version use the same variable, Syft fails to detect the cycle when trying to dereference the variable.

I've marked this ready to pick up.

[kzantow]

This has been fixed in Syft 1.12.2 (by #3170), I'm going to go ahead and close this issue but please do reopen if the latest version does not fix the issue for you!