This is a downtime notification for all IPFire services. We are going to move our servers from one data center to another one and will take the whole project offline during that time.

We will be down on Friday, July 19th from 1 pm UTC for about 4 hours

The reason is that we are physically moving our servers from one part of our hoster's data center to another one where we will be able to grow our infrastructure better and take advantage of some investments our hoster has made into their infrastructure.

All services will be affected by this and hopefully be back up within this downtime window. You will be able to install packages and updates as usual because those are being downloaded from our network of mirror servers, but installing a new system during this time won't be able to download any updates or packages.

We apologise for all inconvenience caused. Doing it all in one go will allow us to do the migration in a lot less time and help us to grow the project!


This is the official release announcement for IPFire 2.23 - Core Update 134. This update ships security fixes in the Linux kernel for the "SACK Panic" attack as well as some other smaller fixes.

SACK Panic (CVE-2019-11477 & CVE-2019-11478)

The Linux kernel was vulnerable for two DoS attacks against its TCP stack. The first one made it possible for a remote attacker to panic the kernel and a second one could trick the system into transmitting very small packets so that a data transfer would have used the whole bandwidth but filled mainly with packet overhead.

The IPFire kernel is now based on Linux 4.14.129, which fixes this vulnerability and fixes various other bugs.

The microcode for some Intel processors has also been updated and includes fixes for some vulnerabilities of the Spectre/Meltdown class for some Intel Xeon processors.

Misc.

  • Package updates: bind 9.11.8, unbound 1.9.2, vim 8.1
  • The French translation has been updated by St├ęphane Pautrel and translates various strings as well as improving some others
  • We now prefer other cipher modes over CBC when IPFire itself opens a TLS connection. CBC is now considered to be substantially weaker than GCM.
  • Email addresses entered in the web UI can now contain underscores.
  • The Captive Portal now comes up properly after IPFire is being rebooted.

This is a different kind of announcement today. Unfortunately our service provider for credit card payments has disabled our account without any further notification. That means we can no longer collect donations via credit card or direct debit. If you have a bank transfer set up, you are fine.

A little bit of a backstory

About two weeks ago, an attacker tried to use presumably stolen credit card information on our donation form. He was able to try around 300 different numbers in only a few hours before we noticed this and tried to block him. We consulted with the technical support hotline of our payment provider.

Unfortunately, the risk department decided to disable our account at the same time before we could implement some better protection against fraud like this and was not able to contact us about it. After endless calls with them and lots and lots of promises about being called back, I was finally able to get hold of someone who told me that they are no longer able to provide their services to us - without any specific reason.

This is not the first time that an open source project has been fallen victim to being cut off of their payments and it is indeed threatening to the existence of all those projects. Now it seems to be our turn.

To not go too much into detail, this seems to be a case of that our payment provider terminated our contract because of one simple reason: They do not know what an Open Source project is and how donations work. The concept does not seem to be anything that they can understand or are willing to learn. It would have helped us to know this when we set up our donations system with them, but unfortunately we could not foresee this.

Some parts of the banking business in Germany really seems to be living in the eighteen-hundreds. The Germans being people who overwhelmingly prefer to pay things in cash, this does not come as a surprise. As a tourist I can only recommend to bring some cash to wherever you go or you won't be able to pay. Something that works the other way round in our neighbouring countries or elsewhere. Credit cards work everywhere.

We also love credit cards. They are an easy and secure way for us to collect donations and they have helped us to fund the IPFire project slightly better - not as much as we have wished for, but we are doing better than before.

Of course it again comes as no surprise that you guys, our dear IPFire users, are privacy-aware and care about where your data is going. That is why we wanted to make sure that we are using a service that is based in Germany - or at least the EU - to comply with data protection laws and of course is able to process donations in Euro. That seems to have failed. The industry is using APIs that have been set up in the 90s or not very shortly after; they are not secure and they have not been paying attention to our warnings about how easily those could be broken.

The banking industry needs an urgent upgrade

Now, we are looking for something new. Please stay with us, because it might be a little while.

We are looking for a new payment provider that lives in this century and give us access to a modern and solid API, that is easy to use and most importantly: secure. We need someone who understands how Open Source projects work, how crowd-funding works and who supports us with our fundraising efforts. Finally, we also want to make sure that we can do all these things within the legal boundaries of the European Union and provide you with the most privacy-focussed way to donate.

That is why we prefer bank transfers as they are very very common in Germany, Austria and Switzerland; as well as credit cards which are simply the most common payment method in the world. We also want to offer direct debit, because it is a cheaper than credit cards.

But we do not want to use PayPal who have a very bad track-record of supporting Open Source projects. We do not want to use any fancy startup payment methods or use other large corporations to process those because this is entirely unnecessary to share our donors with them and is not even cheaper. Ultimately we want that most of your donations is invested into the project and not spent on payment processing fees.

The company with whom we did those payments before definitely is not the right partner - I am not going to name them, because this particular problem is in my view more a problem of the whole industry than only with this company. In the past there have been various problems and communication has always been a huge struggle. In fact, I have never been treated so badly and have never heard so many excuses for their poor service in all of my professional career.

So to close this whole matter I would like to apologise for my fellow team members, who would have benefitted immensely from those donations that we now won't have for some time. To our donors who are supporting us and who are now going to be inconvenienced by this.

I hope that we will be able to continue collecting your recurring donations as soon as we are set up with someone new and that we can then spend our time on actually working on IPFire.