Dear Maintainer,

I ran this Bash command in /etc/logcheck/ignore.d.server/ directory:

for f in *
do
	echo $f================
	while read line
	do
		grep -E "$line" /dev/null 2>&1
		[[ "$?" = 2 ]] && echo $line
	done < $f
done

The grep complained about more than hundred of regular expressions. Sample:

courier================
grep: Unmatched [, [^, [:, [., or [=
^(w{3} [ :0-9]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ ((imap|pop3)(login|d-ssl)|cou
riertcpd): (LOGOUT|TIMEOUT|DISCONNECTED), ip=[[.:[:alnum:]]+](, port=[[[:digit:]
]+])?, headers=[[:digit:]]+, body=[[:digit:]]+$

cron-apt================
grep: Invalid range end
^(w{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ cron-apt: CRON-APT RUN
[[-[:alnum:]/]+]: w{3} w{3} [ [:digit:]]+ [:[:digit:]]{8} w{3,4} [[:digit:]]{4}$
grep: Unmatched [, [^, [:, [., or [=

smartd================
grep: Unmatched ( or \(
^(w{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ smartd[[[:digit:]]+]: Device: /dev/[^[:space:]]+( [[_/[:alnum:][:space:]]+])?( [SAT])?, Temperature changed (-|+)?[1-3]+ Celsius to ([0-4]?[[:digit:]]|5[0-4]) Celsius since last report$

ssh================
grep: Invalid character class name
^(w{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ sshd[[[:digit:]]+]: reverse mapping checking getaddrinfo for [._[:alnum:]-]+ ([[:.[:xdigit:]]+] )?failed - POSSIBLE BREAK-?IN ATTEMPT!$

sympa================
grep: Invalid collation character
^(w{3} [ :0-9]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ wwsympa[[0-9]+]: [robot [._[:alnum:]-]+] [client [0-9.]{7,15}] [user [^[:space:]]+] do_home$


IMHO it would be useful to examine the reported lines.

Gabor

IMHO it would be useful to examine the reported lines.


some of these have been removed for trixie, but i think not all -- in
practice grep seems not always give the warning, even though every reported
line is matched against every regexp (?) so i suppose.we can live with it
for trixie? (most have been unchanged for years).

not for trixie, but we should do this check as part of the autopkgtest

It seems grep regards differently the command line pattern and the
-f patternfile.

Command
for f in * ; do echo $f================; grep -E -f $f /dev/null 2>&1 ; done
reports only two problems:
...
login================
grep: login:8: Unmatched ( or \(
...
systemd================
grep: systemd:21: Unmatched ( or \(
...

But both comes from comments:
# old messages, no longer seen (?)
# services with Restart=always ((eg console-getty.service)



IMHO the most cases the problem is that literal square brackets
are unescaped. E.g.

| courier================
| grep: Unmatched [, [^, [:, [., or [=
| ^(w{3} [ :0-9]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ ((imap|pop3)(login|d-ssl)|couriertcpd): (LOGOUT|TIMEOUT|DISCONNECTED), ip=[[.:[:alnum:]]+](, port=[[[:digit:]]+])?, headers=[[:digit:]]+, body=[[:digit:]]+$

ip=[[.:[:alnum:]]+] and port=[[[:digit:]]+] are suspicious.
I guess they should be ip=\[[.:[:alnum:]+]\] and \[[[:digit:]+]\] .

| cron-apt================
| grep: Invalid range end
| ^(w{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ cron-apt: CRON-APT RUN [[-[:alnum:]/]+]: w{3} w{3} [ [:digit:]]+ [:[:digit:]]{8} w{3,4} [[:digit:]]{4}$

[[-[:alnum:]/]+] should be \[[-[:alnum:]/]+\] .

| dovecot================
| grep: Unmatched [, [^, [:, [., or [=
| ^(w{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ (dovecot: )?(imap|pop3)-login: Disconnected [[.:[:xdigit:]]+]$

I bet on \[[.:[:xdigit:]]+\] .

| exim4================
| grep: Unmatched [, [^, [:, [., or [=
| ^[-0-9]{10} [0-9:]{8} [-[:alnum:]]+ [=-]> [@._[:alnum:]-]+ <?[@._[:alnum:]-]+>? R=dnslookup T=remote_smtp H=[._[:alnum:]-]+ [[.0-9]{7,15}]$

[[.0-9]{7,15}] is probably \[[.0-9]{7,15}\] .

| horde3================
| grep: Unmatched [, [^, [:, [., or [=
| ^(w{3} [ :0-9]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ .+[[0-9]+]: [horde] Login success for [@._[:alnum:]-]+ [[.0-9]{7,15}] to Horde [on line [0-9]+ of ".+"]$

\[[.0-9]{7,15}] to Horde [on line [0-9]+ of ".+"\]

Cheers

Gabor

this looks like a bug in grep. perhaps you could report it to grep --
i suppose they never tested invalid lines with -f

(but the other issues below we should still fix)

that's good in the sense that we dont need to urgently fix this for
trixie (although the first one doesnt look unmatched!) -- commented
lines are dropped by logcheck anyway,

i think you are be right

yes -  this one is already corrected in the rules that will be in
trixie, i think

looks like it

this file has other issues -- the helo logging format is quite
complex, and you can have an ip in or outside [...].

this file is on the "revise in forky" list anyway i think -- i believe
that it's not actualy matching anything at the moment, because these
lines only go in exim4's log, which is not checked by default

i beleive horde3 is no longer in debian, so this whole file should be
dropped instead