This old issue seems unfixed in our zgrep. > zgrep contains the following gem: > > for i do > [snip] > if test $with_filename -eq 1; then > sed_script="s|^[^:]*:|${i}:|" > else > sed_script="s|^|${i}:|" > fi > $grep $opt "$pat" | sed "$sed_script" > [snip] > done > > Aside of the correctness issues (try to use zgrep on files with e.g. '&' in > names), it leads to obvious fun when zgrep arguments had been obtained > by globbing in an untrusted place. Even with standard sed we have at > least ;w<filename>; to deal with; for GNU sed there's also ;e; on top > of that (execute the contents of pattern space). bzgrep is no better - > it's based on zgrep. > > AFAICS, there are two solutions - one is to do what *BSD had done and > make grep(1) use zlib and libbz; then zgrep et.al. become links to > grep. Another is to quote \, |, ; and newlines, which means extra > invocation of sed(1)...
And the proposed patch by Red Hat: --- zgrep.in +++ zgrep.in @@ -24,7 +24,7 @@
And the proposed patch by Red Hat: --- zgrep.in +++ zgrep.in @@ -24,7 +24,7 @@ PATH="BINDIR:$PATH"; export PATH -prog=`echo $0 | sed 's|.*/||'` +prog=`echo "$0" | sed 's|.*/||'` case "$prog" in *egrep) grep=${EGREP-egrep -a} ;; *fgrep) grep=${FGREP-fgrep -a} ;; @@ -112,12 +112,15 @@ fi $uncompress -cdfq "$i" | if test $files_with_matches -eq 1; then - $grep $opt "$pat" > /dev/null && echo $i + $grep $opt "$pat" > /dev/null && printf "%s\n" "$i" elif test $files_without_matches -eq 1; then - $grep $opt "$pat" > /dev/null || echo $i + $grep $opt "$pat" > /dev/null || printf "%s\n" "$i" elif test $with_filename -eq 0 && { test $# -eq 1 || test $no_filename -eq 1; }; then $grep $opt "$pat" else + i=${i//\\/\\\\} + i=${i//|/\\|} + i=${i//&/\\&} if test $with_filename -eq 1; then sed_script="s|^[^:]*:|${i}:|" else
gzip-1.3.5-r6 now in portage with the fix also we can probably open the bug considering redhat has the fix in their public cvs
Opening.
GLSA 200505-05
