Donations Challenge

by Michael Tremer, Sunday, Updated 14 hours ago

The IPFire Project is entirely independent and funded by donations which is quite a tough thing to do these days. It is hard to get donations when you don't have a budget for advertising and encourage people to do more. Unfortunately, donations are at a record low.

That is why we are starting a new challenge: 150 new long-standing donations by the end of the year. That will set up the project for a great year 2019 - and the future is all we are about!

Every donation matters

We appreciate everyone who contributed to the project in the past and we made very good use of every single penny ever donated to the project. That does not only go for financial contributions, but also all other contributions in form of code and time. But a long-term donation is better because it is not only a single event. It is an investment into the project and a commitment to support it and continuous improvement!

It does not matter if you give little or a lot, but it would be appreciated if everyone gives something. Help us to reach out to others and ask them to donate, too. The more people, the better and the more this becomes a community effort!

Instead of asking for a certain sum, we are just asking for a number of new people supporting us regularly. To help us out more, of course donating more helps more, so please try to give as much as you can.

We have a long way ahead of us and need your help

Through our new website and collaboration with Lightning Wire Labs, we are accepting monthly donations and we recommend to everyone to set up one instead of a one-time donation.

We have also improved on payment methods: We support credit card, SEPA Direct Debit and SEPA Bank Transfer to make it fast and easy for use as well as protect your privacy. Also, they do not collect any high fees which ensures that a maximum of the money is going to the project instead of the payment provider. We no longer support PayPal.

Become a donor today

Head over to our new donation page and help us creating change now! Select "Monthly", choose how much you would like to give and complete the form. Thank you!

Update: So far we have 10 monthly donations! Woooh!

The next IPFire update is ready for testing! It comes with a lot of big fixes and cleanups as well as a couple of new features.

802.11ac WiFi

The IPFire Access Point add-on now supports 802.11ac WiFi if the chipset supports it. This allows better coverage and higher network throughputs. Although IPFire might not be the first choice as a wireless access point in larger environments, it is perfect to run a single office or apartment.

Additionally, a new switch allows to disable the so called neighbourhood scan where the access point will search for other wireless networks in the area. If those are found, 40 MHz channel bandwidth is disabled leading to slower throughput.


  • strongswan 5.7.1: This updated fixes various security vulnerabilities filed under CVE-2018-16151, CVE-2018-16152 and CVE-2018-17540. Several flaws in the implementation that parsed and verified RSA signatures in the gmp plugin may allow for Bleichenbacher-style low-exponent signature forgery in certificates and during IKE authentication.
  • The IO graphs now support NVMe disks
  • The SFTP subsystem is enabled again in the OpenSSH Server
  • Swap behaviour has been changed so that the kernel will make space for a large process when not enough physical memory is available. Before, sudden jumps in memory consumption where not possible and the process requesting that memory was terminated.
  • The backup scripts have been rewritten in Shell and now package all add-ons backups with the main backup. Now, it is no longer required to save any add-on configuration separately.
  • Updated packages: apache 2.4.35, bind 9.11.4-P2, coreutils 8.30, dhcpcd 7.0.8, e2fsprogs 1.44.4, eudev 3.2.6, glibc 2.28, gnutls 3.5.19, json-c 0.13.1, keyutils 1.5.11, kmod 25, LVM2 2.02.181, ntfs-3g 2017.3.23, reiserfsprogs 3.6.27, sqlite, squid 3.5.28, tzdata 2018g, xfsprogs 4.18.0

New Add-Ons

  • dehydrated - A lightweight client to retrieve certificates from Let's Encrypt written in bash
  • frr, an IP routing protocol suite and BGP and OSPF are supported on IPFire. Find out more on their website.
  • observium-agent - An xinet.d-based agent for Observium, a network monitoring platform

Updated Add-Ons

  • clamav has been updated to 0.100.2 and the virus database files have been moved to the /var partition. This makes more space available on the root partition.
  • nfs 2.3.3, haproxy 1.8.14, hostapd 2.6, libvirt 4.6.0, tor

More on Intel's Hardware Bugs

by Michael Tremer, November 6, Updated November 7

It has actually been eleven months ago, when I wrote about the chaotic story called Meltdown and Spectre. It was very clear that those were not to be the only CPU vulnerabilities of that kind and here we are now, almost a year later, and that speculation has become reality.

Why am I writing about this now?

To be honest, there are good sources about all these vulnerabilities elsewhere. People who actually invested a lot of time into all of this - more than I can do. Therefore I would not at all call myself an expert on any of those. I guess this not only a result of my limited time, but also Intel and other vendors trying to make sure that as little information is out there as possible. That results in news stories that are based on only very few facts and a lot of speculation.

It is frustrating. But now, I think we have seen a turn in this matter. Unfortunately, not for the better.


Yesterday, the IPFire people had a conversation about the latest addition to the show: PortSmash. Hardware vulnerabilities are something that is coming up all the time, but also a conversation that rotates around itself. We all agree on one thing: We need to do something against it. But what? Not knowing the full detail of the issue does not help. This is also a little outside of the scope of the IPFire project and should be handled in the Linux kernel. But there, the situation is basically the same. Confusion, little action because of various reasons and if there are patches available, they are coming late and are often not well tested or have a significant performance impact.

That means all available solutions always have a huge trade-off. This time, the offered solution is of another quality: Turn off Hyper-Threading.

Turning off Hyper-Threading

In all fairness, not only Intel is affected here, but the PortSmash story is about Intel again. They have not revealed a lot about this vulnerability and do not intend to do so. Therefore, the researchers who found out about it, recommend to disable Hyper-Threading. It definitely mitigates the problem. But at what price?

Hyper-Threading - or SMT in general - works. In many use-cases - and that includes firewalls - they double performance. You are literally getting another CPU core. Disabling it will roughly half the performance of any hardware. That might be acceptable in a single case, but I am quite sure that this is not an option for a large cloud provider to just build another data center and by every bit of hardware they own again.

The question we debated was: Should we disable SMT in IPFire? OpenBSD has quite controversially decided to do so, but we decided that we should not do it. We cannot make that decision for the users. In some situations it might be the right thing to do, in some others it might not be. Although considering security first, it is not the only thing there is to consider.

We also think, that this is not the only thing to do. You, the users, need to take care of your hardware. Install BIOS updates. Make sure that firmware for every component is up to date, patched and that anything you don't need or want (I am looking at you, Intel Management Engine) is disabled. This is something that we as an OS vendor, cannot do for you.

Where are we going?

I do not know. Again, this time it is not only an Intel issue. It is a problem that is very deep within the design of modern processors. Nothing that can be fixed without replacing the CPU. Obviously that is not possible with all the smartphones, laptops and other devices out there that have it soldered on. But even for a socketed CPU, there is no alternative CPUs to buy that have these problems fixed. And even if they did, the list of vulnerabilities is getting longer and longer (I cannot even remember the names of all of them any more) and you would need to replace your CPU again and again and again... An endless game. Some serious action is required. But I guess the recommendation to disable HT is a sign for resignation rather than anything else. So it is not only me who doesn't know. Security researches who are deep in this topic do not know either.

But it is not all doom and gloom

Since I tend to end these blog posts on such a dark note, I want to highlight that IPFire is very well patched against anything that is possible to protect against. We ship a recent kernel that receives all fixes that are built into the Linux kernel, we harden the user-space where possible. IPFire is better protected than others, but developing and distributing patches takes time and effort. In the meantime it is up to you to decide if you can afford to disable HT.