add --stdin flag to use find for excluding of files, folders and mount points
#75
Conversation
|
This is a merged version of #43 |
|
Current version build from this RP: |
|
As always, thanks for your work in this repo @beckerr-rzht ! :) Can you told me, which is here the best solution to call the script? Currently I'm using this like this: https://github.com/pthoelken/log4j-searcher/blob/55f263aad20ed29f36f3476cfebb1ee3c0524f3b/runner.sh#L58 but I'm not sure if it's work correctly. The script is done really fast. Can you give me your preffered method how do you would start the jar which should check the whole linux/mac beginning from / I'll ask you because when I check with samples from https://github.com/mergebase/log4j-samples/tree/master/true-hits he told me this: usually it should be like this: (show here for example) Thanks a lot and happy new year! |
|
I use a script that looks more or less like this: #!/bin/bash -e
tmpdir=$(mktemp -d)
cd "$tmpdir"
cleaner() {
echo "* Removing $tmpdir"
rm -rf "${tmpdir:-does-not-exist}"
}
trap cleaner INT TERM EXIT
detector="https://github.com/beckerr-rzht/log4j-detector/raw/release/log4j-detector-2021.12.29.jar"
m="$(dpkg --print-architecture 2>/dev/null || uname -m)"
case "$m" in
armsf) jre="https://cdn.azul.com/zulu-embedded/bin/zulu11.52.13-ca-jdk11.0.13-linux_aarch32sf.tar.gz" ;; # RPI
armhf) jre="https://cdn.azul.com/zulu-embedded/bin/zulu11.52.13-ca-jdk11.0.13-linux_aarch32hf.tar.gz" ;; # RPI
*64) jre="https://cdn.azul.com/zulu/bin/zulu11.52.13-ca-jre11.0.13-linux_x64.tar.gz" ;; # 64 Bit
i?86) jre="https://cdn.azul.com/zulu/bin/zulu11.52.13-ca-jre11.0.13-linux_i686.tar.gz" ;; # 32 Bit
*) echo "ERROR: No java for $m" 2>&1; exit 1
esac
echo -n "* Downloading: jre ... "
wget -qO - "$jre" | tar xzf - && echo OK
echo -n "* Downloading detector ... "
wget -q "$detector" && echo OK
java=$(find . -name java -type f -executable| head -1)
if [ -z "$java" ]; then
echo "java not found" >&2
exit 1
fi
find_opt=(
/
\( -type d \( -fstype autofs -o -fstype fuse.sshfs -o -fstype nfs -o -fstype proc -o -fstype sshfs -o -fstype sysfs -o -fstype tmpfs \) -prune -o -type f \)
-not -path \*/.snapshots/\*
-not -path \*/.m2/repo/\*
-type f -print
)
echo "* Scanning using $java and ${detector##*/}:"
while read line; do
case "$line" in
"-- Problem"*" encrypted "*) ;; # HIDE
"-- Problem"*".zip.ZipException"*) ;; # HIDE
"-- Problem"*".io.EOFException"*) ;; # HIDE
"-- Problem"*"no magic number"*) ;; # HIDE
"-- Problem"*"not find ZIP magic"*);; # HIDE
"-- Problem"*"malformed") ;; # HIDE
"-- Problem"*"invalid distance"*) ;; # HIDE
"-- Problem"*) echo " ${line#-}";; # SHOW (unknown problems)
"-- "*);; # HIDE
*" _POTENTIALLY_SAFE_"*);; # HIDE
*" _OLD_");; # HIDE (for the moment)
*) echo " - $line" ;; # SHOW (the rest)
esac
done < <(find "${find_opt[@]}" | "$java" -jar ${detector##*/} --stdin 2>&1 || true)Which produces, for example, this output: |
What surprises me: |
Right. Currently I can test this at Windows (CYGWin) only. Thanks for your script. I will test this in the next few days. |
Have you considered using WSL? |
Yea, I know but at my business workstation wsl doesn't work correctly atm (VirtualBox, Hyper-V, Docker ... struggle) but I can test it in the evening on my home desk. |
|
What you also could try: |
|
Why not use powershell and Get-ChildItem and end up using Linux stuff in
Windows?
…On Thu, Jan 6, 2022, 10:26 beckerr-rzht ***@***.***> wrote:
What you also could try:
The findutils are available in a variant for Windows (See
http://gnuwin32.sourceforge.net/packages/findutils.htm).
The output of find and the path syntax used by java should then be more
compatible.
I haven't tested this yet, but the example looks promising:
[image: grafik]
<https://user-images.githubusercontent.com/15359213/148352406-6a533f26-f01a-4228-9d8b-5bc2a0517360.png>
—
Reply to this email directly, view it on GitHub
<#75 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAI4X4KR7LDQWU445VFH2PTUUVG25ANCNFSM5LANS5LQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
You are right about that, of course. But the actual question and my workaround referred to an existing bash script: |
|
For your explain: This script is not for windows environment. I've just code it on a windows computer because my macbook is still in delivery. When I have to be code this for windows env, of course I choose ps1. |
|
Ok then my bad. I was missing this context when I decided to reply.
…On Thu, Jan 6, 2022, 11:10 Patrick Thoelken ***@***.***> wrote:
For your explain: This script is *not for* windows environment. I've *just
code it* on a windows computer because my macbook is still in delivery.
When I have to be code this for windows env, of course I choose ps1.
—
Reply to this email directly, view it on GitHub
<#75 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAI4X4IB5SXZ25NUU4S7RK3UUVL73ANCNFSM5LANS5LQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
No problem :) |
Fixes #42