Am 12.11.2021 um 23:33 schrieb Bernhard Bitsch: > 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. Reinstalled my test prints. The processing I saw till now: - update is called waiting for lock ( 7 x sleep(1) ) - no output( lockfile does not exist ) Each - block describes a call of the .cgi Next I'll add some timing information. > 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 >>> >> >>