Bug#1025420: exim4: ${run}expansion fail Bug stiill open [TT#2568022]
oh, well, thanks for analysing that.
Sorry, I didn't notice the change myself.
Am 25.10.23 um 16:24 schrieb Andreas Metzler:
On 2023-10-23 SerNet Support Kevin Ivory wrote:
[...]
That binary does not fix the problem of quote with space included:
# /usr/sbin/exim4 -be '${run{/usr/bin/echo ${quote:hello world}}}'
Failed: Expansion of "${quote:hello" from command "/usr/bin/echo ${quote:hello
world}" in ${run} expansion failed: missing } at end of string
[...]
${run expansion changed in 4.96:
"If the option preexpand is not used, the command string is split into
individual arguments by spaces and then each argument is expanded."
i.e.
/usr/bin/echo ${quote:hello world}
is split into
/usr/bin/echo
${quote:hello
world}
and the second string yields an expansion error.
Use
/usr/sbin/exim4 -be '${run,preexpand{/usr/bin/echo ${quote:hello world}}}'
to get the old behavior.
Beste Grüße
Kevin Ivory (SerNet Support)
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-37-0, mailto:kont...@sernet.de
Gesch.F.: Dr. Johannes Loxen und Reinhild Jung
AG Göttingen: HR-B 2816 - http://www.sernet.de
Datenschutz: https://www.sernet.de/datenschutz
Besuchen Sie den SerNet Stammtisch
Nächster Termin, Infos & Anmeldung
unter https://sernet.de/stammtisch
Bug#1025420: exim4: ${run}expansion fail Bug stiill open [TT#2568022]
Hi Andreas,
I installed the package
https://people.debian.org/~ametzler/tmp/exim4-daemon-heavy_4.96-15+deb12u2+almostu3_amd64.deb
The binary /usr/sbin/exim4 inside is from Sept 3rd:
-rwsr-xr-x 1 root root 1575384 2023-09-03 13:34 /usr/sbin/exim4
That binary does not fix the problem of quote with space included:
# /usr/sbin/exim4 -be '${run{/usr/bin/echo ${quote:hello world}}}'
Failed: Expansion of "${quote:hello" from command "/usr/bin/echo ${quote:hello
world}" in ${run} expansion failed: missing } at end of string
Am 23.10.23 um 18:06 schrieb Andreas Metzler:
I have uploaded pre built binaries to
https://people.debian.org/~ametzler/tmp/
Best regards
Kevin Ivory (SerNet Support)
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-37-0, mailto:kont...@sernet.de
Gesch.F.: Dr. Johannes Loxen and Reinhild Jung
AG Göttingen: HR-B 2816 - http://www.sernet.de
Datenschutz: https://www.sernet.de/datenschutz
Bug#1025420: exim4: ${run}expansion fail Bug stiill open [TT#2568022]
Hello Andreas,
thanks for the info.
I am not familiar with the Repository format at
https://salsa.debian.org/exim-team/exim4/-/tree/12_bookworm?ref_type=heads
Is there a binary or a package that I can test or do
I have to patch and compile?
Am 23.10.23 um 14:29 schrieb Andreas Metzler:
On 2023-10-18 SerNet Support Kevin Ivory wrote:
Hello Andreas,
I just realized Debian Bug #1025420 is closed even though
we are still running into it in exim 4.96-15+deb12u2
Please try:
# /usr/sbin/exim4 -be '${run{/usr/bin/echo ${quote:hello world}}}'
Failed: Expansion of "${quote:hello" from command "/usr/bin/echo ${quote:hello
world}" in ${run} expansion failed: missing } at end of string
The bug is only fixed for exactly the version in the bug
report, variables with no space included. We need to use
${quote:$h_subject:} where the subject often includes
spaces.
Hello,
Yes, I now that. I had a stable update pending for the latest point
release but I pulled it because there needed to be DSA for CVE-2023-42114,
CVE-2023-42115, CVE-2023-42116 at basically the same time.
I would appreciate if you could check whether
https://salsa.debian.org/exim-team/exim4/-/tree/12_bookworm?ref_type=heads
works for you.
cu Andreas
Best regards
Kevin Ivory (SerNet Support)
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-37-0, mailto:kont...@sernet.de
Gesch.F.: Dr. Johannes Loxen and Reinhild Jung
AG Göttingen: HR-B 2816 - http://www.sernet.de
Datenschutz: https://www.sernet.de/datenschutz
Bug#965012: RFT: squid3 3.5.23-5+deb9u5, please test [TT#2407228]
Hi Markus, thanks for investing even more time. All tests so far look good. The examples we had work correctly now. The http://:0 messages in the Avira Icap usage have ended as well. Am 29.09.20 um 00:11 schrieb Markus Koschany: [adding Andreas and Kevin to CC who helped with testing past squid3 updates] Hello, I have uploaded a new version of squid3 for Stretch to people.debian.org. https://people.debian.org/~apo/lts/squid3/stretch/ It contains fixes for CVE-2020-15049, CVE-2020-15810, CVE-2020-15811 and CVE-2020-24606. Let me know if you find any regressions from the current released version 3.5.23-5+deb9u4. Best regards Kevin Ivory (SerNet Support) -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: 0551-37-0, mailto:kont...@sernet.de Gesch.F.: Dr. Johannes Loxen und Reinhild Jung AG Göttingen: HR-B 2816 - http://www.sernet.de
Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]
Hi Markus, Oliver had submitted a bug report to Avira OEM integration support and they have finally analyzed the problem. The developer states that it is a problem of the (Debian or Mint) Squid build that does not occur in a vanilla build of the standard squid3 package. German message below. I will try a translation here: "after analyzing the situation, our development confirms this behavior with Linux Mint squid version 3.527 as well. To all appearances, the squid server answers the request with "http://:0"; URL so that ICAP answers the same. Excerpt of cache.log: (see below) ... Our developer then compiled a stock Squid version 3.5.27 with similar compiler flags as the default squid. This version did not reply with " http://:0"; URL. We cannot decide if this problem occurs if it is a problem with the squid build or a random error." ### end of my translation Here the original statement in German language: ##- Please type your reply above this line -## Your request (303525) been updated. To add additional comments, reply to this email. Gerhard Boscher (Avira OEM Integration Support) Sep 25, 2020, 10:44 GMT+2 Hallo Herr Ivory, nach Untersuchung der Situation stellte unsere Entwicklung bpsw. ebenso mit der default Version von Squid unter Linux Mint - 3.527. ein gleiches Verhalten fest. Allen Anschein nach sendet bereits der Squid Server die "http://:0"; URLs auf einen Request, so dass ICAP diese in seiner Antwort ebenfalls wiedergibt. Auszug aus der cache.log: 2020/09/07 14:14:22.182 kid1| 93,9| ModXact.cc(198) handleCommConnected: will write [FD 12r;rw(1)G/R job9]: REQMOD icap://127.0.0.1:1344/service_scanner-reqmod ICAP/1.0 Host: 127.0.0.1:1344 Date: Mon, 07 Sep 2020 12:14:22 GMT Encapsulated: req-hdr=0, null-body=233 Allow: 204 HEAD http://:0 HTTP/1.0 User-Agent: w3m/0.5.3+git20170102 Accept: text/html, text/*;q=0.5, image/*, application/*, message/* Accept-Encoding: gzip, compress, bzip, bzip2, deflate Accept-Language: en;q=1.0 Host: www.sernet.de Nachdem unser Entwickler eine Squid Version 3.5.27 selbst kompilierte , dabei ähnliche Flags verwendete wie die beim system default squid, arbeitete diese Version ohne dass die "http://:0"; URL auftrat. Wir können abschließend leider nicht sagen ob dies eine Problematik des Squid Servers ist die bei system-default builds auftritt oder evtl. zufällig. Mit freundlichen Grüßen / Best regards Gerhard Boscher Specialist OEM Integration Support Engineer Am 04.09.20 um 15:09 schrieb Markus Koschany: Hello Oliver, Am 04.09.20 um 09:44 schrieb SerNet Support Oliver Seufer: Hello Markus, This is Oliver. I just did some more troubleshooting and I found the error message in the debug logfile: kid1| 23,3| url.cc(471) urlParse: urlParse: Split URL 'http://:0' into proto='http', host='', port='0', path='/' kid1| 23,3| url.cc(492) urlParse: urlParse: Invalid port '0' [...] So my initial thought is that squid works correctly in this case. This is the header which squid needs to parse. ICAP/1.0 200 OK ISTag: "10017;4140202;836248;8189206" Server: AVIRA ICAP (1.21.1.61) X-Response-Info: Clean Encapsulated: req-hdr=0, null-body=215 HEAD http://:0 HTTP/1.0 User-Agent: w3m/0.5.3+git20170102 Accept: text/html, text/*;q=0.5, image/*, application/*, message/* Accept-Language: en;q=1.0 Host: www.sernet.de Accept-Encoding: gzip,bzip2,deflate The HEAD http://:0 HTTP/1.0 is weird. It starts with the http protocol but there is no domain name and port 0 obviously does not exist. This probably used to work because the squid3 parser was less strict before. I would try to change the output of your AVIRA server. Is there a reason why it has to send this specific HEAD line in the first place and can you modify it? Best regards Kevin Ivory (SerNet Support) -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: 0551-37-0, mailto:kont...@sernet.de Gesch.F.: Dr. Johannes Loxen und Reinhild Jung AG Göttingen: HR-B 2816 - http://www.sernet.de
Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]
Hello Markus, we are having problems extracting a test case with debug data. The problem arises sporadically on our customer systems with HTTP POST or PUT, rarely with GET, sometimes with out HTTP monitoring, sometimes with Debian updates. Since I haven't been able to create a test case on our debug vm system, I have created a debug file on a customer system. Since the POST data might be critical to the customer, is there any way to extract only the data you need? All cases in my debug log (46 GB) seem to be of a POST that is logged in access.log as 2020-08-27 11:29:24 1243 172.16.100.3 TAG_NONE/500 3640 POST http://srv1.first-businesspost.com/viper? - HIER_NONE/- text/html The debug cache.log does contain SenderID= and Secret= Am 18.08.20 um 21:38 schrieb Markus Koschany: On Tue, 18 Aug 2020 13:37:30 +0200 SerNet Support Kevin Ivory wrote: Hi Markus, On Thu, 13 Aug 2020 21:56:14 +0200 Markus Koschany wrote: Version: 3.5.23-5+deb9u3 thanks for the work on the patches. We have two different ICAP dependent packages. After installing squid 3.5.23-5+deb9u3, ICAP worked for Avira ICAP, but it did not work for our squid-redirector package for BPjM index file. The cache.log shows 2020/08/18 07:24:04 kid1| suspending ICAP service for too many failures 2020/08/18 07:24:04 kid1| essential ICAP service is suspended: icap://127.0.0.1:1344/service_scanner-reqmod [down,susp,fail11] I guess its time for me to set up a test machine for debugging output. The default debug level shows not enough information to reproduce or understand the problem. Please set debug_options to ALL,9 and send me your cache.log and squid.conf file via private email. Regards Kevin Ivory (SerNet Support) -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: 0551-37-0, mailto:kont...@sernet.de Gesch.F.: Dr. Johannes Loxen und Reinhild Jung AG Göttingen: HR-B 2816 - http://www.sernet.de
Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]
Hi Markus, On Thu, 13 Aug 2020 21:56:14 +0200 Markus Koschany wrote: Version: 3.5.23-5+deb9u3 thanks for the work on the patches. We have two different ICAP dependent packages. After installing squid 3.5.23-5+deb9u3, ICAP worked for Avira ICAP, but it did not work for our squid-redirector package for BPjM index file. The cache.log shows 2020/08/18 07:24:04 kid1| suspending ICAP service for too many failures 2020/08/18 07:24:04 kid1| essential ICAP service is suspended: icap://127.0.0.1:1344/service_scanner-reqmod [down,susp,fail11] I guess its time for me to set up a test machine for debugging output. Best reagrds Kevin Ivory (SerNet Support) -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: 0551-37-0, mailto:kont...@sernet.de Gesch.F.: Dr. Johannes Loxen und Reinhild Jung AG Göttingen: HR-B 2816 - http://www.sernet.de
Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]
Just for the sake of completeness: we have this problem as well and still have many systems with Debian Stretch that need Squid Icap to communicate with Avira Savapi antivirus. Because this bugs hits us as well, we are now holding on to version 3.5.23-5+deb9u1. On Mon, 27 Jul 2020 00:15:18 +0200 Markus Koschany wrote: Hello Andreas, On Tue, 14 Jul 2020 13:57:48 +0200 Andreas Schulz wrote: > Package: squid > Version: 3.5.23-5+deb9u2.1 > Severity: important > File: /usr/sbin/squid > > Dear Maintainer, > > We installed the security update deb9u2 and learned that no more > http-access (with icap) was possible. I am not the maintainer but I have prepared the security update for squid3 in Stretch. So far you are the only one who reported this problem. I had sent a request for testing but never received any feedback. [1] Please note that Stretch is now supported by the LTS team. We have a dedicated mailing list where you can report problems dedicated to packages in Stretch called debian-...@lists.debian.org. Could you set debug_options to ALL,9 (which should enable full debugging according to the squid wiki) and reproduce the issue again? Please attach the complete log either to this bug report or send it to me via private email directly. The patch for CVE-2019-12523 contains only one line that appears to touch icap related code in src/adaptation/icap/ModXact.cc. I have reverted this change and attached a new CVE-2019-12523.patch. Could you apply it and report back if it makes any difference? Otherwise only the debug log could help to narrow down the problem. Regards, Markus [1] https://lists.debian.org/debian-lts/2020/07/msg00018.html Best regards Kevin Ivory (SerNet Support) -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: 0551-37-0, mailto:kont...@sernet.de Gesch.F.: Dr. Johannes Loxen und Reinhild Jung AG Göttingen: HR-B 2816 - http://www.sernet.de
