Michael Tremer

IPFire 2.19 - Core Update 119 is available for testing
by Michael Tremer, February 26

Hello Community,

it is time for another Core Update that updates the toolchain of the distribution as well as a number of smaller bug and security fixes. Therefore this update is another one of a series of general housekeeping updates to make IPFire better, faster and of course more secure!

Thanks for the people who contributed to this Core Update by submitting their patches and please help us to support everyone’s work with your donation!

Toolchain Updates

The toolchain is a collection of programs that is used to build the distribution. One of the most important one is the compiler GCC which has been updated to version 7.3.0 which mainly adds support for retpoline. This is needed to build protection against Spectre into newer kernels.

The main C library, glibc, has been updated to version 2.27 and brings various stability fixes, performance improvents and bug fixes.

Other toolchain packages that have been updated: binutils 2.30, ccache 3.4.1, diffutils 3.1.6, swig 3.0.12

Security-Relevant Changes



The following packages have been updated: asterisk 13.18.5, bacula 9.0.6, bwm-ng 0.6.1-f54b3fa, flac 1.3.2, haproxy 1.8.0, nginx 1.13.7, nut 2.7.4, openvmtools 10.2.0, postfix 3.2.4, powertop 2.9, sarg 2.3.11, stunnel 5.44

These packages have been dropped and will be removed with this Core Update: lcr, mysql which was very outdated and is not needed by any add-ons.

Michael Tremer

IPFire 2.19 - Core Update 118 is almost there
by Michael Tremer, February 6

Hello Community,

the next Core Update 118 is almost there. We have no major new bugs left any more and it is good to go. But before our release engineering team pulls the trigger and is releasing this for everyone of you, we would like to make you aware again that a number of add-on packages has been discontinued and will automatically be uninstalled when Core Update 118 is installed. Those are:

PHP is being removed for security reasons and for more and more of the software that we ship becoming independent from it. If you have installed any custom applications that use PHP, please move them to another machine.

We are sending you this deprecation announcement to give you some extra time to prepare for the upcoming changes in case you have missed them from the pre-announcement of this Core Update.

Michael Tremer

IPFire 2.19 - Core Update 118 is available for testing
by Michael Tremer, January 29

Hello community,

the next Core Update for IPFire is now ready for testing and will be released soon. Please support is with that to provide you with a number of security and bug fixes as well as some new features.

Thanks for the people who contributed to this Core Update by submitting their patches and please help us to support everyone’s work with your donation!

Spring Clean

It is the time of the year where we reviewed large parts of the distribution and decided to drop support for various packages and add-ons that cannot be maintained any more:

Most importantly, this Core Update drops support for PHP and therefore various add-ons that rely on it. We have taken that decision some while ago without any objections and first dropped all add-ons that are not supported and updated by their respective authors and maintainers. That left us with only one package that needed PHP but also be installed anywhere else.

PHP is a huge problem to maintain and does not really have a place on a firewall in 2018. Our web user interface is entirely independent and since we value security more than anything else, we have decided to drop support for PHP with this Core Update.

If you have anything installed manually that requires PHP, please move it to another web server before installing this Core Update.

Add-ons that have also been dropped: cacti, openmailadmin, phpSANE, nagios because icinga is available, nagiosql, mediatomb, owncloud


This Core Update originally contained the microcode updates that Intel has now pulled from public release. Since they make the system very unstable and cause random reboots and reportedly can render some systems unbootable, we decided to remove them from the update again.

So far due to the hardening Meltdown exploits do not work on IPFire although this still is a hardware bug and software can only be modified to mitigate this massive problem. Over the coming days and weeks we will continue to work on providing a solution that mitigates all problems, but so far we are not in a position to have patches for Linux that fix them all and are at the same time complete and stable enough to be released.

Security Improvements

Update Accelerator Improvements

Justin Luth has contributed fixes and improvements for the Update Accelerator which has sometimes re-downloaded files with special characters in the URL (#10504).

He has also improved caching of Microsoft updates which is now based on a checksum of the update file (#11558).



New Add-ons
Michael Tremer

Meltdown/Spectre - The chaotic story
by Michael Tremer, January 12

I am sure that it has been unmissable: Every modern processor has unfixable security flaws. The story has now been boiling for weeks and has finally made the main news one week ago.

To make this article shorter, I won’t go into details of the technical issue. That has been discussed in many places so far and everyone of you can search around a bit to find an explanation to your desired detail. The most important piece of information that you should know is that the CPUs are allowing applications to access parts of the memory that they should not and that allows an attacker to get important information from the victim’s computer.

Although it took decades to find out about this fundamental design issue, it is very easy to exploit and even a little piece of Javascript executed in a web browser has been reported to be sufficient to execute the attack.

The most important question for us is: Is IPFire affected? And the unfortunate answer is yes, most likely. This is a hardware bug and if IPFire is running on hardware that is vulnerable, it is affected. The even worse news is that there is probably not many systems that are not affected. The IPFire kernel has been patched and hardened against multiple attack vectors and there is a possibility that we are able to mitigate at least some exploitation of this attack through grsecurity. However, this is not 100% confirmed, yet.

Another argument that probably weighs a bit more is that IPFire is never supposed to run untrusted code. The example with the javascript code in a browser might work on a desktop system, but the firewall does not do this. All code is reviewed and compiled by us, signed and verified before it is installed on every single IPFire system. As long as you haven’t installed any third-party software from any other source you should be safe. But any unknown and therefore unpatched remote code execution vulnerability in any of the many packages that IPFire is using would allow an attacker to execute an Meltdown/Spectre exploit. That means we cannot just lean back.

Talking about what we can do from a distribution point of view brings me to point that I have to raise first: I have never read so many speculations, false assumptions and comments that were just wrong about any vulnerability before. For me, new about this vulnerability are just breaking and so are the patches that are out there to mitigate the problem. Many things are just in the unknown until today. The biggest problem there seems to be the embargo that hasn’t been followed properly and one specific vendor who is following their own rules.

It is still officially unconfirmed if 32 bit architectures are affected as well. Logic tells us they are, but the Linux kernel maintainers who pride themselves in having delivered a good set of patches have only working on the 64 bit x86 version of it and not 32 bit. So all 32 bit systems remain unpatched.

The latest versions of the kernel (4.14 and 4.15-rc*) have received a patchset called KAISER which is supposed to mitigate the hardware bug. However, only an old version and parts of that patchset have been backported to older kernels. IPFire is always based on an older kernel that is on long-term support and well maintained just like many other distributions. Some have patched parts of the vulnerability but I think I can be certain that nobody fixes all of it. By that I certainly do not want to say that the kernel maintainers are doing a bad job. They are doing a great job, but of course their time is also limited and this is not a simple fix that requires a few lines like Heartbleed did. It requires major rework of some essential parts of the kernel and I am very grateful for them doing that work. My point is just that they are not done, yet and deploying half a fix is probably not a good idea. People have reported bugs in the other kernels that will probably never be fixed.

So what will IPFire do? Having said that we think that we might already mitigate some portion of that problem and that the distribution is not too easy to exploit, we are continuing to work on rebasing the distribution on 4.14 which is the latest long-term supported kernel. That will take some more time though since supporting ARM is a huge maintenance problem for us right now. It is holding up a release that is basically ready for beta. If a good patchset that is also compatible with grsecurity becomes available we will ship that with the current kernel, but I am not expecting that to happen in the near future.

That leaves me with saying that everyone who can should probably upgrade from 32 bit to 64 bit.

I cannot finish this article with having a rant about Intel and how they dealt with this issue. There are also some other groups who deserve some criticism and but clearly Intel did not handle this well and is still trying to play down the huge size of this problem. First of all it is the most severe hardware issue that has been around in probably all time. It is not only in a product that some people use, but probably every person who reads this article owns at least one Intel processor that has been produced in the last decade. Their power in the market is that huge that they have a monopoly.

Bugs happen. I do not want to point a finger at a certain person or group who did something wrong. Clearly they should have known better, but this has happened now, so we have to deal with it. But you should own your bugs. Take responsibility. Instead their PR department seems to have chosen a route to blame other vendors as well for a bug that only they had. Yes, ARM and yes, AMD is also affected by some problems that are also very severe, but there is one that only affects Intel processors. That is also the most severe one. They continue to put out benchmarks that only show a little performance impact but deliberately neglect older processors where the performance impact is a lot higher.

That is not a very good way to gain my trust. And not that I had the biggest trust in that company before, this did not help. So I am stuck in a world where I do not have many alternatives to what I can buy from the shelfs. Your products are inside every modern computer. Make yourself aware of that responsibility. That includes your CEO who apparently did not want to own that financial risk.

And the only reason why I care about this so much is, that secure software requires secure hardware. It does not matter how secure IPFire is, because when the hardware is compromised, the software is compromised, too.

Hottest posts 2018 2017 2016 2015 2014 2013 2012 2011