From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Core Update 161 (testing) report Date: Wed, 10 Nov 2021 13:48:06 +0100 Message-ID: In-Reply-To: <09818f9c-36a7-149c-3e43-24ca689c4b0e@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0110234196741585880==" List-Id: --===============0110234196741585880== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi All, My input is very simple. The update occurred without any hiccups and every th= ing I have been able to evaluate looks to be working fine. No problems found. Regards, Adolf. On 04/11/2021 22:07, Bernhard Bitsch wrote: > Hello, > > Am 04.11.2021 um 13:37 schrieb Michael Tremer: >> Hello, >> >>> On 2 Nov 2021, at 10:58, Bernhard Bitsch wrote: >>> >>> Hello, >>> >>> Am 02.11.2021 um 11:34 schrieb Michael Tremer: >>>> Hello, >>>>> On 2 Nov 2021, at 08:01, Peter M=C3=BCller = 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 know= n so far. >>>> Yay \o/ >>>>> During the upgrade, I noticed the Pakfire CGI still does not display lo= g messages as it >>>>> used to do, but at least there is now a spinning loading icon displayin= g the message that >>>>> an operation is currently in progress. From a UX perspective, this is o= kay I guess. >>>> What is different about it? >>> >>> I've implemented the changes also ( took them from the patches ). >>> I found this difference, too. The 'old' state is, that the messages of th= e last pakfire call are displayed. The patch tries to show the actual update = progress. But nothing of it is displayed. >> >> I still don=E2=80=99t quite understand. >> >> When you click the update button and confirm that you want to install some= thing, you should see a screen with a message that =E2=80=9CPakfire is busy= =E2=80=9D and an animated icon. >> >> At the bottom of the page, you might see some log lines from /var/log/mess= ages. If you have too much stuff being logged, you might not see much here. >> >> What do you get? >> >> The behaviour should be the same since the beginning of IPFire 2. >> > > I get the animated icon and the "Pakfire is busy" message, but no log excer= pts. This behaviour is new with this patch. > Are there other changes in the general page routines and description ( CSS = ), which I've overseen? > I've changed pakfire.cgi only. > >>> >>>>> The reconnection necessary for upgrading pppd went smooth, albeit Pakfi= re 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 don=E2=80=99t download packages over a VPN. So I can liv= e with this. >>>>> To my surprise, some IPsec N2N connections did not reconnect automatica= lly, even after >>>>> rebooting the testing machine. After manually clicking on one of the "r= estart" buttons >>>>> on the IPsec CGI, they came back instantly, and have been stable ever s= ince. >>>> Anything in the logs? It should come back automatically. >>>>> This affected N2N connections not being in the "on-demand" mode only. W= hile it is not >>>>> really a show-stopper if someone is sitting in front of his/her/its IPF= ire machine, remote >>>>> upgrades might be tricky. >>>> Indeed. Could you please investigate further whether this is or is not a= regression introduced in this update? >>>>> Apart from that, this update looks quite good to me. The IPS changes ar= e 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 suitabl= e for everyone, >>>>> hence massively increasing security without worrying too much of perfor= mance 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. Switchin= g protocols might >>>>> be an issue, starting with TLS, while using something completely differ= ent 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. >>>>> 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=C3=BCller >>>> -Michael >>> >>> - Bernhard >> --===============0110234196741585880==--