Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem,new logwatch sends mails with charset UTF-8
> -Original Message- > From: 'Klaus Ethgen' [mailto:kl...@ethgen.de] > Sent: Sunday, January 01, 2017 14:42 > To: Jason Pyeron > Cc: 'Willi Mann'; 849...@bugs.debian.org; > logwatch-de...@lists.sourceforge.net > Subject: Re: Bug#849531: [Logwatch-devel] Bug#849531: > Possible security problem,new logwatch sends mails with charset UTF-8 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Am So den 1. Jan 2017 um 20:24 schrieb Jason Pyeron: > > Yes, 8-bit ASCII, here is a translation table. > > ASCII is 7 bit. > > All 8 bit are different encodings. Sorry, "extended" ascii (code page 437), been using it since 1984 and old naming habits die hard. > > > > Below 128 it is not a problem as UTF-8 is transparent in this > > > range. But > > > above 128 it _is_ a problem. > > > > No, only when not ENCODED properly. > > Well, exactly what I said. > > > UTF-8 is very, very, likely going to stay. > > I would wish that it would die as it is bad designed and have some bad > behaviour, technical wise. > > However, I am realistic enough to know that it will not be possible to > replace UTF-8 with better design's. It is like IPv6, there is > no Plan B. > > Just I will only use UTF-8 where it is cleary specified (like XML) or > where it is the only possible way to go. With everything else I stay > with latin1. But this is just my personal view. > > Regards >Klaus > - -- > Klaus Ethgen > http://www.ethgen.ch/ > pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen > <kl...@ethgen.ch> > Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C > -BEGIN PGP SIGNATURE- > Comment: Charset: ISO-8859-1 > > iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhpW38ACgkQpnwKsYAZ > 9qzrIgwAlGkTGVpJEp1XKYNcpUF2hR7Ie6vlA3xFBfCacCDAjJx5gIrGLkX5d8Ay > rus3hblp/Gv+r+IpzUrRyk5gifBAfaDWVnuj1j8Qi9dLFyhnQaD0LX8/MBgV6wOn > A2/C+XedX1geoZxk7c/m6b59XaWAuN36JK8PJjpoWX/8MNqDoNYAr31gMrZkHwmw > IYZygbLom22qcSq4ZeowWY5ZUX9nqku0/9NNzBYtegB/YIWxbzxWNaOIPhgPouZ5 > Ejjd14NBap4ZT263Bc55L+tvCBX2BU1iFipmKa5pRslexF3UdscR1e20b0wWVTaP > HTkcNJggsNQVUpPYyxp6xUWkmaItZCMSSHC77sv4ur6jnRY8IolUlh+x68ZEayIn > yU5O/rjg3tMbNaZHTOZcNZNtOisNOMm19SOkwNCezKdods8BhAI0z9I7rnDaOumT > HefdprK0CTuylGKdAvBxJv6io3AKkNdTaZ32bFnfE2HtaX77ZNDTgXkmutE1og6t > UeF6fw/T > =Mr6M > -END PGP SIGNATURE- >
Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem,new logwatch sends mails with charset UTF-8
> -Original Message- > From: 'Klaus Ethgen' [mailto:kl...@ethgen.de] > Sent: Sunday, January 01, 2017 12:23 > To: Jason Pyeron > Cc: 'Willi Mann'; 849...@bugs.debian.org; > logwatch-de...@lists.sourceforge.net > Subject: Re: Bug#849531: [Logwatch-devel] Bug#849531: > Possible security problem,new logwatch sends mails with charset UTF-8 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Am So den 1. Jan 2017 um 17:38 schrieb Jason Pyeron: > > > What do you want to say with that? Your input is not in UTF-8. > > > > That is the point. The OP complaines about ASCII being sent > when labeld as UTF8, as such it created invalid UTF8 sequences. > > No, I complain about non UTF-8 being send as UTF-8. > > Namelly, bytes values 0-255. Yes, 8-bit ASCII, here is a translation table. ASCII|UTF-8 00 | 00 01 | 01 ... 7E | 7e 7F | 7f 80 | c2 80 81 | c2 81 ... BE | c2 be BF | c2 bf C0 | c3 80 C1 | c3 81 ... FE | c3 be FF | c3 bf > > Below 128 it is not a problem as UTF-8 is transparent in this > range. But > above 128 it _is_ a problem. No, only when not ENCODED properly. UTF-8 is very, very, likely going to stay. -Jason
Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem,new logwatch sends mails with charset UTF-8
> -Original Message- > From: Willi Mann [mailto:wi...@debian.org] > Sent: Sunday, January 01, 2017 08:27 > To: Jason Pyeron; 849...@bugs.debian.org > Cc: 'Klaus Ethgen'; logwatch-de...@lists.sourceforge.net > Subject: Re: Bug#849531: [Logwatch-devel] Bug#849531: > Possible security problem,new logwatch sends mails with charset UTF-8 > > Hi, > > Am 2017-01-01 um 00:20 schrieb Jason Pyeron: > > Not exactly a valid test, besides it works for me. The > issue is internal ascii data being written as ascii but > instructing consumers > > it is uft8. > > > > $ cat utf8_test.pl > > #!/usr/bin/perl > > # > > use strict; > > use File::Slurp; > > > > my $inputfile = @ARGV[0]; > > my $logfilecontent = read_file($inputfile); > > binmode(STDOUT, ":utf8"); > > print $logfilecontent; > > > > $ ./utf8_test.pl testlog.txt > > übersät > > > > $ ./utf8_test.pl testlog.txt | hexdump -C > > c3 bc 62 65 72 73 c3 a4 74 0a > |..bers..t.| > > 000a > > > > $ hexdump.exe -C testlog.txt > > fc 62 65 72 73 e4 74 0a > |.bers.t.| > > 0008 > > What do you want to say with that? Your input is not in UTF-8. That is the point. The OP complaines about ASCII being sent when labeld as UTF8, as such it created invalid UTF8 sequences. Quoting https://en.wikipedia.org/wiki/UTF-8#Codepage_layout > Invalid byte sequences[edit] > > Not all sequences of bytes are valid UTF-8. A UTF-8 decoder should be > prepared for: > * the red invalid bytes in the above table [192,103,245-255] > * an unexpected continuation byte > * a leading byte not followed by enough continuation bytes (can happen in > simple > string truncation, when a string is too long to fit when copying it) > * an overlong encoding as described above > * a sequence that decodes to an invalid code point as described below > > Many earlier decoders would happily try to decode these. Carefully crafted > invalid > UTF-8 could make them either skip or create ASCII characters such as NUL, > slash, > or quotes. Invalid UTF-8 has been used to bypass security validations in > high-profile > products including Microsoft's IIS web server[14] and Apache's Tomcat servlet > container.[15] > > > Just for the record, the output what I posted originally: We have differences > > % ./utf8_test.pl testlog > übersät > % ./utf8_test.pl testlog | hexdump -C > c3 83 c2 bc 62 65 72 73 c3 83 c2 a4 74 0a > |berst.| > 000e > % hexdump -C testlog > c3 bc 62 65 72 73 c3 a4 74 0a > |..bers..t.| > 000a $ hexdump.exe -C testlog.txt fc 62 65 72 73 e4 74 0a |.bers.t.| 0008 > > Bye > Willi >
Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem,new logwatch sends mails with charset UTF-8
> -Original Message- > From: Klaus Ethgen > Sent: Saturday, December 31, 2016 08:48 > To: Willi Mann > Cc: Jason Pyeron; 849...@bugs.debian.org; logwatch-de...@lists.sourceforge.net > > Hi, > > Am Sa den 31. Dez 2016 um 14:28 schrieb Willi Mann: > > thanks for your test cases. However, I don't think that > binmode provides > > an acceptable solution, at least not alone. While it > ensures that the > > strings are valid utf-8 strings, it will convert any valid utf-8 > > character to two "garbage" characters. Try Not exactly a valid test, besides it works for me. The issue is internal ascii data being written as ascii but instructing consumers it is uft8. $ cat utf8_test.pl #!/usr/bin/perl # use strict; use File::Slurp; my $inputfile = @ARGV[0]; my $logfilecontent = read_file($inputfile); binmode(STDOUT, ":utf8"); print $logfilecontent; $ ./utf8_test.pl testlog.txt übersät $ ./utf8_test.pl testlog.txt | hexdump -C c3 bc 62 65 72 73 c3 a4 74 0a|..bers..t.| 000a $ hexdump.exe -C testlog.txt fc 62 65 72 73 e4 74 0a |.bers.t.| 0008 > > Well, that "garbage" is by design for UTF-8. If you don't want that, > stay on latin1. > > It is a no-go to set the mime type to UTF-8 but still send latin1. (As > it does the current version.) Setting header to UTF-8 doesn't > change the > content of the mail. It just open up for troubles. > > Regards >Klaus > - -- > Klaus Ethgen > http://www.ethgen.ch/ > pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen > <kl...@ethgen.ch> > Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C > -BEGIN PGP SIGNATURE- > Comment: Charset: ISO-8859-1 > > iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhntxMACgkQpnwKsYAZ > 9qyD4gv/ThmNQDCI9QeXYGvwafNDzcDtaHUpeGhOqJI4NjE/UxvPDGIJsMAmS3fI > w69zDuHmy9d1AsCm4I8ipF9l1LD1GHo8Fh9g2Uiv4l6d5e4jYmMi/L/pJxqbAqIt > A1LjNQUNGMLk97OHLqR5/9lnfOzahdzgEVNP/Fi5ygVXi3vJFdwfFFbWk39CfYUy > jcKQUdDzbQUzyFLl7I+1pZm19HCDH4v5fIzqwQW8bz4VXpTIUZjXJSV2n5gN1Lo9 > 99utKdR1b1UQScdGs2zV/QhVN/IJJsNNzK4Zylisdjw0ZgvnSW3gt461d62FAH1o > R4UwerUZYWzCGLZHpGwPw/1/s7YOAlPlO46UzSslqC0J0mmcCPG5eBz4iX2F03U3 > uoz3gscPsjFAf/eqlkp6MHXeNqSV2cCwQLnqZ17/py5DiMUxS61dFXRmcrLOotC0 > KmDBRC7Gft8dcr4bjqYG3jIv0ppOEdvA1izQQ+q2WNQ4E7AprDPJ94MgibQ8BBYX > iGbaxnj2 > =af5+ > -END PGP SIGNATURE- >
Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8
> -Original Message- > From: Willi Mann > Sent: Friday, December 30, 2016 16:21 > To: Klaus Ethgen; 849...@bugs.debian.org > Cc: logwatch-de...@lists.sourceforge.net > Subject: Re: [Logwatch-devel] Bug#849531: Possible security > problem, new logwatch sends mails with charset UTF-8 > > Hi Klaus, > > Am 2016-12-30 um 18:36 schrieb Klaus Ethgen: > > Hi Willi, > > > > Am Fr den 30. Dez 2016 um 18:18 schrieb Willi Mann: > >> can you elaborate how this could be exploited? > > > > Well, log principally contains untrusted data that could be injected > > from untrusted source. That is no security hole itself. > > > > But when that data gets displayed with the wrong charset, that can > > trigger problems in window managers (for example). See > xterm which can > > be controlled via ansii sequences. Even more, it could > trigger stream > > conversion problems if the UTF-8 implementation is not really fully > > tested with broken streams. You would have the same issue with cat /var/log/x > > So far, I cannot see that the change you mentioned would be > problematic. Adding the binmode(OUTFILE, ":utf8"); fixes your primary report. > What I do see is that it might be wise to sanitize the output of > logwatch. A possible way to go might be to remove any byte > with value < > 0x20 - unless it is a newline or tab. But that is independent of the > ISO-8859-15 to utf-8 change. Please open a new bug for this enhancement, as it a different issue. -Jason
Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem,new logwatch sends mails with charset UTF-8
A very rudimentary test: /projects/logwatch $ perl -e 'for ($i=0; $i<256; ++$i) {print chr($i);}' | hexdump.exe -C 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f || 0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f || 0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f | !"#$%&'()*+,-./| 0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f |0123456789:;<=>?| 0040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f |@ABCDEFGHIJKLMNO| 0050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f |PQRSTUVWXYZ[\]^_| 0060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f |`abcdefghijklmno| 0070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f |pqrstuvwxyz{|}~.| 0080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f || 0090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f || 00a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af || 00b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf || 00c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf || 00d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df || 00e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef || 00f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff || 0100 /projects/logwatch $ perl -e 'binmode(STDOUT, ":utf8"); for ($i=0; $i<256; ++$i) {print STDOUT chr($i);}' | hexdump.exe -C 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f || 0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f || 0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f | !"#$%&'()*+,-./| 0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f |0123456789:;<=>?| 0040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f |@ABCDEFGHIJKLMNO| 0050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f |PQRSTUVWXYZ[\]^_| 0060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f |`abcdefghijklmno| 0070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f |pqrstuvwxyz{|}~.| 0080 c2 80 c2 81 c2 82 c2 83 c2 84 c2 85 c2 86 c2 87 || 0090 c2 88 c2 89 c2 8a c2 8b c2 8c c2 8d c2 8e c2 8f || 00a0 c2 90 c2 91 c2 92 c2 93 c2 94 c2 95 c2 96 c2 97 || 00b0 c2 98 c2 99 c2 9a c2 9b c2 9c c2 9d c2 9e c2 9f || 00c0 c2 a0 c2 a1 c2 a2 c2 a3 c2 a4 c2 a5 c2 a6 c2 a7 || 00d0 c2 a8 c2 a9 c2 aa c2 ab c2 ac c2 ad c2 ae c2 af || 00e0 c2 b0 c2 b1 c2 b2 c2 b3 c2 b4 c2 b5 c2 b6 c2 b7 || 00f0 c2 b8 c2 b9 c2 ba c2 bb c2 bc c2 bd c2 be c2 bf || 0100 c3 80 c3 81 c3 82 c3 83 c3 84 c3 85 c3 86 c3 87 || 0110 c3 88 c3 89 c3 8a c3 8b c3 8c c3 8d c3 8e c3 8f || 0120 c3 90 c3 91 c3 92 c3 93 c3 94 c3 95 c3 96 c3 97 || 0130 c3 98 c3 99 c3 9a c3 9b c3 9c c3 9d c3 9e c3 9f || 0140 c3 a0 c3 a1 c3 a2 c3 a3 c3 a4 c3 a5 c3 a6 c3 a7 || 0150 c3 a8 c3 a9 c3 aa c3 ab c3 ac c3 ad c3 ae c3 af || 0160 c3 b0 c3 b1 c3 b2 c3 b3 c3 b4 c3 b5 c3 b6 c3 b7 || 0170 c3 b8 c3 b9 c3 ba c3 bb c3 bc c3 bd c3 be c3 bf || 0180 This confirms that binmode utf8 is needed to print out the full ASCII range. > -Original Message- > From: Jason Pyeron [mailto:jpye...@pdinc.us] > Sent: Friday, December 30, 2016 14:03 > To: Jason Pyeron; 'Willi Mann'; logwatch-de...@lists.sourceforge.net > Cc: 849...@bugs.debian.org; 849531-forwar...@bugs.debian.org; > 'Klaus Ethgen' > Subject: RE: [Logwatch-devel] Bug#849531: Possible security > problem,new logwatch sends mails with charset UTF-8 > > I have opened https://sourceforge.net/p/logwatch/bugs/56/ . > > I am working a test case for this right now. > > As I see it, there are 3 paths to test. > > Output as STDOUT, file, and email. In each case does an 8bit > value (0x00..0xff unsigned) result in a valid UTF-8 character. > > Is binmode(STDOUT, ":utf8") needed? Does it fix the issue if > it was needed? > > > > -Original Message- > > > From: Willi Mann > > > Sent: Friday, December 30, 2016 12:18 > > > To: logwatch-devel > > > Cc: 849...@bugs.debian.org; > 849531-forwar...@bugs.debian.org; Klaus Ethgen > > > What would be your suggested fix? > > > $ git show f9db5949c58321175bda66310156f43ae607109f > commit f9db5949c58321175bda66310156f43ae607109f > Author: bjorn <bjo...@users.sourceforge.net> > Date: Sat Oct 15 17:38:40 2016 -0700 > > Changed encoding to UTF-8, as suggeste
Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem,new logwatch sends mails with charset UTF-8
I have opened https://sourceforge.net/p/logwatch/bugs/56/ . I am working a test case for this right now. As I see it, there are 3 paths to test. Output as STDOUT, file, and email. In each case does an 8bit value (0x00..0xff unsigned) result in a valid UTF-8 character. Is binmode(STDOUT, ":utf8") needed? Does it fix the issue if it was needed? > > -Original Message- > > From: Willi Mann > > Sent: Friday, December 30, 2016 12:18 > > To: logwatch-devel > > Cc: 849...@bugs.debian.org; 849531-forwar...@bugs.debian.org; Klaus Ethgen > > What would be your suggested fix? $ git show f9db5949c58321175bda66310156f43ae607109f commit f9db5949c58321175bda66310156f43ae607109f Author: bjornDate: Sat Oct 15 17:38:40 2016 -0700 Changed encoding to UTF-8, as suggested by Goran Uddeborg. diff --git a/scripts/logwatch.pl b/scripts/logwatch.pl index 0f863dc..0167755 100755 --- a/scripts/logwatch.pl +++ b/scripts/logwatch.pl @@ -1162,9 +1162,9 @@ sub initprint { } #Config{output} html if ( $Config{'format'} eq "html" ) { -$out_mime .= "Content-Type: text/html; charset=\"iso-8859-1\"\n\n"; +$out_mime .= "Content-Type: text/html; charset=\"UTF-8\"\n\n"; } else { -$out_mime .= "Content-Type: text/plain; charset=\"iso-8859-1\"\n\n"; +$out_mime .= "Content-Type: text/plain; charset=\"UTF-8\"\n\n"; } if ($Config{'hostformat'} eq "split") { #8.0 check hostlimit also? or ne none?
Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8
> -Original Message- > From: Willi Mann [mailto:wi...@debian.org] > Sent: Friday, December 30, 2016 12:18 > To: logwatch-de...@lists.sourceforge.net > Cc: 849...@bugs.debian.org; 849531-forwar...@bugs.debian.org; > Klaus Ethgen > Subject: Re: [Logwatch-devel] Bug#849531: Possible security > problem, new logwatch sends mails with charset UTF-8 > > Hi Klaus, > > can you elaborate how this could be exploited? It does not make the list at http://unicode.org/reports/tr36/ , but bad utf-8 **may** cause email programs to behave badly. A google for unicode crash brings up the iPhone message processing issues... > What would be your suggested fix? Not sure it is a high risk issue, but perl should use binmode(STDOUT, ":utf8"); to encode the perl strings as utf-8. > > I'm including the upstream mailing list in the conversation. > > thanks you > Willi > > Am 2016-12-28 um 10:09 schrieb Klaus Ethgen: > > Package: logwatch > > Version: 7.4.3+git20161207-1 > > Severity: critical > > > > Current logwatch did change from sending mails with charset iso-8859-1 > > to UTF-8. This openes up a potential security hole as UTF-8 is not able To give context... commit f9db5949c58321175bda66310156f43ae607109f Author: bjornDate: Sat Oct 15 17:38:40 2016 -0700 Changed encoding to UTF-8, as suggested by Goran Uddeborg. diff --git a/scripts/logwatch.pl b/scripts/logwatch.pl index 0f863dc..0167755 100755 --- a/scripts/logwatch.pl +++ b/scripts/logwatch.pl @@ -1162,9 +1162,9 @@ sub initprint { } #Config{output} html if ( $Config{'format'} eq "html" ) { -$out_mime .= "Content-Type: text/html; charset=\"iso-8859-1\"\n\n"; +$out_mime .= "Content-Type: text/html; charset=\"UTF-8\"\n\n"; } else { -$out_mime .= "Content-Type: text/plain; charset=\"iso-8859-1\"\n\n"; +$out_mime .= "Content-Type: text/plain; charset=\"UTF-8\"\n\n"; } if ($Config{'hostformat'} eq "split") { #8.0 check hostlimit also? or ne none? > > to display all 8bit data. > > > > This is especially true as the output from logwatch is from > untrusted > > source where there could easily put some malicious content > in. Logwatch > > does nothing to cleanup the mail content or convert it from > the native > > charset to UTF-8. > > > > Note that this bug went in recently as 7.4.0 did not have this bug > > (neither does 7.4.1). I do not find any upstream changelog in the > > package and when I download it from upstream directly, I > cannot find any > > note of this breaking change. > > > > -- System Information: > > Debian Release: stretch/sid > > APT prefers unstable > > APT policy: (500, 'unstable'), (500, 'testing'), (1, > 'experimental') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 4.7.10 (SMP w/8 CPU cores) > > Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) > > Shell: /bin/sh linked to /bin/dash > > Init: sysvinit (via /sbin/init) > > > > Versions of packages logwatch depends on: > > ii exim4-daemon-light [mail-transport-agent] 4.88~RC6-2 > > pn perl:any > > > > Versions of packages logwatch recommends: > > ii libdate-manip-perl 6.56-1 > > ii libsys-cpu-perl 0.61-2+b1 > > pn libsys-meminfo-perl > > > > Versions of packages logwatch suggests: > > ii fortune-mod 1:1.99.1-7 > > > > -- no debconf information > > > > > > > -- > > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Logwatch-devel mailing list > logwatch-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/logwatch-devel >