From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Core Update 161 (testing) report Date: Wed, 10 Nov 2021 15:00:04 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7474769197890386059==" List-Id: --===============7474769197890386059== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Thank you for all your feedback. I think we can look at a release very soon. -Michael > On 10 Nov 2021, at 12:48, Adolf Belka wrote: >=20 > Hi All, >=20 > My input is very simple. The update occurred without any hiccups and every = thing I have been able to evaluate looks to be working fine. No problems foun= d. >=20 > Regards, >=20 > Adolf. >=20 > On 04/11/2021 22:07, Bernhard Bitsch wrote: >> Hello, >>=20 >> Am 04.11.2021 um 13:37 schrieb Michael Tremer: >>> Hello, >>>=20 >>>> On 2 Nov 2021, at 10:58, Bernhard Bitsch wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> Am 02.11.2021 um 11:34 schrieb Michael Tremer: >>>>> Hello, >>>>>> On 2 Nov 2021, at 08:01, Peter M=C3=BCller wrote: >>>>>>=20 >>>>>> Hello *, >>>>>>=20 >>>>>> Core Update 161 (testing; no release announcement or changelog has bee= n published, yet) >>>>>> is running here for about 12 hours by now without any major issues kno= wn so far. >>>>> Yay \o/ >>>>>> During the upgrade, I noticed the Pakfire CGI still does not display l= og messages as it >>>>>> used to do, but at least there is now a spinning loading icon displayi= ng the message that >>>>>> an operation is currently in progress. From a UX perspective, this is = okay I guess. >>>>> What is different about it? >>>>=20 >>>> I've implemented the changes also ( took them from the patches ). >>>> I found this difference, too. The 'old' state is, that the messages of t= he last pakfire call are displayed. The patch tries to show the actual update= progress. But nothing of it is displayed. >>>=20 >>> I still don=E2=80=99t quite understand. >>>=20 >>> When you click the update button and confirm that you want to install som= ething, you should see a screen with a message that =E2=80=9CPakfire is busy= =E2=80=9D and an animated icon. >>>=20 >>> At the bottom of the page, you might see some log lines from /var/log/mes= sages. If you have too much stuff being logged, you might not see much here. >>>=20 >>> What do you get? >>>=20 >>> The behaviour should be the same since the beginning of IPFire 2. >>>=20 >>=20 >> I get the animated icon and the "Pakfire is busy" message, but no log exce= rpts. 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. >>=20 >>>>=20 >>>>>> The reconnection necessary for upgrading pppd went smooth, albeit Pakf= ire 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 li= ve with this. >>>>>> To my surprise, some IPsec N2N connections did not reconnect automatic= ally, 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. >>>>>> 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 IP= Fire 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 a= re 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 suitab= le for everyone, >>>>>> hence massively increasing security without worrying too much of perfo= rmance impacts. >>>>>>=20 >>>>>> (For the sake of completeness: Unfortunately I did not yet have time d= o conduct a penetration >>>>>> test against this. Personally, I can imagine the IPS changes permittin= g some attacks >>>>>> after Suricata decided it cannot analyse a connection further. Switchi= ng protocols might >>>>>> be an issue, starting with TLS, while using something completely diffe= rent afterwards. >>>>> I expected you to bring this up a lot earlier and it is indeed a concer= n. Although I think it is a theoretical one: >>>>> * You cannot really change back from a TLS connection on any applicatio= n that I am aware of >>>>> * Suricata only does this if it is very very certain that the connectio= n 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.) >>>>>>=20 >>>>>> 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) >>>>>>=20 >>>>>> I am looking forward to the release of Core Update 161. >>>>>>=20 >>>>>> Thanks, and best regards, >>>>>> Peter M=C3=BCller >>>>> -Michael >>>>=20 >>>> - Bernhard >>>=20 --===============7474769197890386059==--