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: Thu, 04 Nov 2021 22:07:12 +0100 Message-ID: <09818f9c-36a7-149c-3e43-24ca689c4b0e@ipfire.org> In-Reply-To: <5347116B-E586-4DEC-9C98-E871FFBA6ADA@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5597379819925501574==" List-Id: --===============5597379819925501574== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Am 04.11.2021 um 13:37 schrieb Michael Tremer: > Hello, >=20 >> 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 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 ok= ay 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 the= last pakfire call are displayed. The patch tries to show the actual update p= rogress. 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 somet= hing, 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/messa= ges. 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 I get the animated icon and the "Pakfire is busy" message, but no log=20 excerpts. This behaviour is new with this patch. Are there other changes in the general page routines and description (=20 CSS ), which I've overseen? I've changed pakfire.cgi only. >> >>>> The reconnection necessary for upgrading pppd went smooth, albeit Pakfir= e 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 live= with this. >>>> To my surprise, some IPsec N2N connections did not reconnect automatical= ly, even after >>>> rebooting the testing machine. After manually clicking on one of the "re= start" buttons >>>> on the IPsec CGI, they came back instantly, and have been stable ever si= nce. >>> Anything in the logs? It should come back automatically. >>>> This affected N2N connections not being in the "on-demand" mode only. Wh= ile it is not >>>> really a show-stopper if someone is sitting in front of his/her/its IPFi= re 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 are= really noticeable, >>>> and bring a throughput I think I never experienced with IPFire and the I= PS 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 perform= ance 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 differe= nt 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 w= anted 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 >=20 --===============5597379819925501574==--