https://www.ipfire.org/blog/ipfire-2-29-core-update-192-is-available-for-testing
5 Likes
Nice 
I will clone my present 191 installation to a second SSD *) and try out the 192 update a.s.a.p.
Best regards
Willy Sejr
*) This way all I need to do in case of major problems is to shut down my appliance and swap the NVMe SSD.
And for anyone wondering:
I’ve recently updated my IPfire device to a new Asus Intel N-200 “MiniPC” because of supported HW and easy NVMe SSD replacement because my former Asus “MiniPC” was 12 years+ old and starting to show its age. 
I had to spend a little money on a new NVMe SSD compatible cloning device, but purely because I find “the cloning method” a lot easier than “back-up and restore” 
1 Like
Been running for a day with no issues observed. RPZ survived the update as well; )
2 Likes
Upgrade went smoothly via WUI
1 Like
Updated last night with no issues. Have not noticed any problems since the update.
1 Like
Hi.
I’ve also updated and everything seems to be fine.
Good job guys 
.
Cheers.
1 Like
I would happily try it, but the ISO creation fails (file created, zero bytes) on my IPFire 2.29 (aarch64) - Core-Update 191
There is a bug in the backup.cgi
ISO backup is only working for x86_64
Also most aarch64 machines are not booting from an iso so this backup is useless.
1 Like
Updated from 191 production to 192 development without any problems.
192 development running smoothly. 
1 Like
Do we think it’s a bit late to include OpenSSL 3.4.1 in CU192, given the advisory to update yesterday?
Thanks,
A G
1 Like
I will add this…
4 Likes
It’s not a bad thing to get it installed quickly but I believe that IPFire is not affected by this CVE.
We use x509 certificate chains for everything related to OpenSSL and not RPK’s (Raw Public Keys) and the vulnerability is related to the use of RPK’s.
RPK’s are disabled by default in OpenSSL and checking our openssl config file they are not enabled by us, in which case even if a client is using RPK’s, IPFire will not respond by replacing the x509 certificates with RPK’s.
I have just found that RPK’s were first introduced in OpenSSL-3.2 and we have not changed anything in terms of the certificate sets we use for anything for a long time before that version.
So I am pretty certain we do not use RPK’s and therefore are not vulnerable to this CVE.
6 Likes
Appreciate your efforts Arne!
Interesting post, Adolf.
Thanks
A G
Been testing cu 192 and so far no apparent problems.
Screenshot included showing lowered average CPU, but not as ultimately low as lowest previously. Intel Pentium Silver N6000 CPU for reference.
After weekly reboot, load jumped massively, but can’t see anything obvious, or raised CPU.
Are you able to grab a screenshot of htop during the CPU spike?
Thanks,
A G
The first spike was 191 → 192 update The drops coincide with scheduled rebooting.
The only thing I need to figure out is how to do a speed test inside the networks to benchmark the 10Gb connections, but I can observe the difference when I swap the ipfire router out for a netgear router. Ipfire runs so much better.
Hello, all. By my reckoning, the last build for 192 testing was on 19 February (commit 2112342d). Does anyone know when we might expect release?
Probably not too long. Some people have been away for a while.
The feedback and status of the CU192 Testing Release is on the agenda for the next conf call on 10th Mar. I don’t expect any further changes, so I would expect that it will be agreed to do a full release at that conf call, so probably later next week, unless there is something unexpected on the 10th Mar.
4 Likes
