Is there any option to pinpoint actual dependency from there?
Yes, but you need to know the offending OpenSSL version and you need grep
. Windows find
won’t do.
First, take note of the offending OpenSSL version. For sake of argument, say its due to OpenSSL 1.0.1h
.
Next, gather a list of your dependencies and their top level folders. For sake of argument, say its $HOME/Desktop/aosp-app
, $HOME/sdk-a
, /usr/local/sdk-b
and /opt/local/sdk-c
.
Finally, for the top level directories:
grep -R '1.0.1h' "$HOME/Desktop/aosp-app"
grep -R '1.0.1h' "$HOME/sdk-a"
grep -R '1.0.1h' /usr/local/sdk-b
grep -R '1.0.1h' /opt/local/sdk-c
You don’t need grep -iR
, which is a case insensitive (-i
) recursive (-R
) search. You also don’t need grep -IR
, which is a recursive (-R
) search that skips binary files (-I
).
All of this works because OpenSSL library embeds its version in the data section as a string. Eventually, you will hit on the culprit, which is probably an SDK that comes pre-built as a shared object but includes OpenSSL as a static library. One SDK seems to be identified frequently, and it uses cURL which is built against a static OpenSSL library.
If you have JAR files and suspect them, then you can perform the following as a quick test:
find <dir> -name '*.jar' -exec grep -R '1.0.1h' {} \;
The command will look in the directory <dir>
and its subdirectories. It will search for files with the *.jar
extension. When it finds one, it will run grep
on it looking for the string. find
will do it for every *.jar
it finds.