From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernhard Bitsch To: development@lists.ipfire.org Subject: Re: Core Update 161 (testing) report Date: Fri, 12 Nov 2021 23:33:54 +0100 Message-ID: <277b2e5f-45f5-b6e8-71a6-086c2ef15ddb@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0960051232435214866==" List-Id: --===============0960051232435214866== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi, as far as I saw in the code, the new CGI tries the refreshing of the tail -f also. But it is never displayed. I tried to search by test prints, but had no success, yet. Because I didn't test the real CU 161, I'm not sure I've implemented all changes ( especially these new systemxxx functions). So I decided to stop this research. I'll give a new try next days. Regards, Bernhard Am 12.11.2021 um 19:54 schrieb Kienker, Fred: > Peter - the behavior you describe also happens on all our testing > systems. It took us several tries to realize the systems hand not just > locked up. > > Michael - this is a regression from previous behavior. > > There is never any indication to the user the update processing has been > completed. The tailf of the update log provided an indication of when > the processing is completed. > > Best regards, > Fred > > Please note: Although we may sometimes respond to email, text and phone > calls instantly at all hours of the day and night, our regular business > hours are 9:00 AM - 6:00 PM ET, Monday thru Friday. > > -----Original Message----- > From: Peter Müller > Sent: Friday, November 12, 2021 12:32 PM > To: Michael Tremer > Cc: IPFire: Development > Subject: Re: Core Update 161 (testing) report > > Hello Michael, > > thanks for your mail. Please excuse my tardy reply - I currently have a > lot of other things on my plate, and 24 hours per day are not sufficient > to get them done. > > [Insert personal load average graph here] > >> Hello, >> >>> On 2 Nov 2021, at 08:01, Peter Müller > wrote: >>> >>> Hello *, >>> >>> Core Update 161 (testing; no release announcement or changelog has >>> been published, yet) is running here for about 12 hours by now > without any major issues known so far. >> >> Yay \o/ >> >>> During the upgrade, I noticed the Pakfire CGI still does not display >>> log messages as it used to do, but at least there is now a spinning >>> loading icon displaying the message that an operation is currently in > progress. From a UX perspective, this is okay I guess. >> >> What is different about it? > The older CGI used to print a "tail -f"-like output of Pakfire's log, > reloading the page every few seconds so the user could see the actual > process of the ongoing operation. > > Nowadays, it only gives a spinning GIF image and a text note - better > than nothing, but the user has no idea what is going on behind the > scenes and how long it will take to be completed. > >> >>> The reconnection necessary for upgrading pppd went smooth, albeit >>> Pakfire could not download add-on upgrades afterwards since the VPN >>> did not came back in time, so I had to do this manually. >> >> Normally people dont download packages over a VPN. So I can live > with this. >> >>> To my surprise, some IPsec N2N connections did not reconnect >>> automatically, even after rebooting the testing machine. After >>> manually clicking on one of the "restart" buttons on the IPsec CGI, > they came back instantly, and have been stable ever since. >> >> Anything in the logs? It should come back automatically. > Unfortunately, I did not yet have time to look at this. > >> >>> This affected N2N connections not being in the "on-demand" mode only. > >>> While it is not really a show-stopper if someone is sitting in front >>> of his/her/its IPFire machine, remote upgrades might be tricky. >> >> Indeed. Could you please investigate further whether this is or is not > a regression introduced in this update? > > Will do. > >> >>> Apart from that, this update looks quite good to me. The IPS changes >>> are really noticeable, and bring a throughput I think I never >>> experienced with IPFire and the IPS turned on. :-) This is certainly >>> worth mentioning, as it finally makes the IPS suitable for everyone, > hence massively increasing security without worrying too much of > performance impacts. >>> >>> (For the sake of completeness: Unfortunately I did not yet have time >>> do conduct a penetration test against this. Personally, I can imagine > >>> the IPS changes permitting some attacks after Suricata decided it >>> cannot analyse a connection further. Switching protocols might be an > issue, starting with TLS, while using something completely different > afterwards. >> >> I expected you to bring this up a lot earlier and it is indeed a > concern. Although I think it is a theoretical one: >> >> * You cannot really change back from a TLS connection on any >> application that I am aware of >> * Suricata only does this if it is very very certain that the > connection can be bypassed and just hope the guys over there know what > they are doing. > Yes. Again, things are quite packet on my end - sorry. > > Indeed, it is a rather theoretical setup: If an attacker already got a > TLS connection established so far that Suricata cannot look into it > anymore, why not use that connection to conduct the malicious > activities? There is no need to do protocol obfuscation anymore. > > Thanks, and best regards, > Peter Müller > >> >>> While I do not really consider this to be a critical attack surface, >>> I wanted to look deeper into this as soon as I have some spare time >>> to do so.) >>> >>> Tested IPFire functionalities in detail: >>> - PPPoE dial-up via a DSL connection >>> - IPsec (N2N connections only) >>> - Squid (authentication enabled, using an upstream proxy) >>> - OpenVPN (RW connections only) >>> - IPS/Suricata (with Emerging Threats community ruleset enabled) >>> - Guardian >>> - Quality of Service >>> - DNS (using DNS over TLS and strict QNAME minimisation) >>> - Dynamic DNS >>> - Tor (relay mode) >>> >>> I am looking forward to the release of Core Update 161. >>> >>> Thanks, and best regards, >>> Peter Müller >> >> -Michael >> > > --===============0960051232435214866==--