The next update is available for testing! This update comes with a new kernel and security enhancements and will hopefully be released as the last maintenance update for this year. This change log is rather short, but the changes are very important.

Linux 4.14.86

The kernel has been updated to the latest version of the Linux 4.14.x branch which brings various improvements around stability, enhances performance and fixes some security vulnerabilities. This kernel also has major updates for the Spectre and Meltdown vulnerabilities that remove previously existent performance penalties in some use-cases.

The kernel's modules are now compressed with the XZ algorithm which will save some space on disk as the kernel is one of the largest components of IPFire.

Misc.

  • openssl has been updated to 1.1.0j and 1.0.2q which fixes some minor security issues and has various bug fixes
  • The bind package has now changed to ship shared libraries which it did not before. Those allow that commands like dig and host use those shared libraries and are no longer statically linked. This makes the files a lot smaller.
  • St├ęphane Pautrel has substancially improved the French translation of IPFire. Thank you very much for that!

Add-ons

  • Updated packages: bird 2.0.2, nano 3.2,
  • New packages: shairport-sync

I have recently talked about how to contribute to the project. As an Open Source project, we always appeal to individuals and ask them for their contributions to make IPFire better - whether that is code or donations.

But today, I would like to talk to the companies that use IPFire and point out a common habit that I have noticed:

There are forks of IPFire

I know for a fact, that many companies out there are maintaining their own fork of IPFire. That is not a full-fledged fork of IPFire with their own website or community. It is rather, that they make a couple of changes to the IPFire system every time they are deploying it.

Those changes can be small. Maybe it is a script that makes monitoring work a little bit easier. Maybe it fixes a couple of minor bugs that we did not find yet. I think these changes technically make their version of IPFire a fork.

But forks are bad. They take away something from a community that should be about giving back instead of everyone working on their own. They immensely create overhead for those companies because work needs to be done over and over again. Not only in the community when a certain bug is found and a fix is being developed although one already exists somewhere out there. It also comes at a high cost for the company that has to adjust their changes and rewrite their patches over and over again when something changes in IPFire. I think everyone can agree on that this is a waste of everybody's time and difficult and painful, too.

Stopped installing updates?

A common recipe against that is that people stop applying updates. I cannot warn strongly enough what a bad idea that is. On fireinfo, we can see that there are many systems running today that have not received latest updates and one often-heard reason for that is that the update "will break our changes" or "the system didn't come back up any more and we had to roll back" and then the system just stays in that state.

Get your changes into IPFire and you will never have to worry about this again.

Come on and contribute back!

Therefore, I would like to invite all the companies out there who are doing this to become a contributor to the Open Source project. Bring in you bug fixes, bring in your smaller features and scripts where you think that only you need them. This is giving something back to the community and you will see very quickly how soon you will benefit from this again, too.

If you think that your code needs to be a little bit polished before it is ready for production, talk to us and get feedback. IPFire developers are available for hire and can help you out.

IPFire will become a lot better through these small contributions and they will make it work in even more environments out there. Tested and approved by you, the community.


When it is getting cold and the long days over summer are over, that is usually the time when developers wake up and get back to work again. Winter is always a good time for software development.

So I would like to invite you all, who have some free time and interest to contribute to the IPFire Project! Instead of always asking for donations, I would like to highlight what is even more valuable for us: Code contributions.

Why?

IPFire is used by many companies in many places all around the world. Although it is ready for production, software is never done. There is always a chance to make IPFire better fit into a environment. However, we, the IPFire developers can only simulate a certain number of these. In all other cases, we rely on the feedback from you!

Start off with a bug fix

Maybe you found a bug that is bothering you and nobody else has discovered it yet. Reporting it is the first step! If you have the right skills, try to fix and propose a patch that can be integrated into the distribution.

There is a category with bugs that are be easy to solve for beginners and a great for learning about this whole process.

How to contribute?

Contributing to IPFire is easy. However, to only allow good-quality code into the distribution, every change has to be peer-reviewed by the other IPFire developers. Only when it has been tested and confirmed that it does not introduce any new bugs and actually fixes a bug, it will be merged into the distribution.

This process is needed to keep IPFire running as well as it is today. It has to be secure, fast and easy to use. Every change needs to make sure that this is never compromised. We have a guide on how to submit patches that helps you with the first steps and has some great tips on how to work with the tools that the IPFire developers use.

Work with the community

If you know how to contribute and have contributed before, start working on bigger things. Maybe you are missing a feature or want to add support for certain hardware that you are using. Whether it is some new code that you are contributing or fixing a bug that changes a couple of lines of existing code, it is strongly recommended to work with the community.

Sometimes there are many ways on how to architect code, what language to use and many other things. It is always helpful to speak to the developers first on how to design a change to get it tested and approved easier. Maybe you can join people who are already working on a certain project. We also help out when you are stuck with an idea. Talk to use on the development mailing list.

We only people on the other end of the keyboard and would like to form a lasting relationship with you to improve IPFire. Come and join us. Get in touch!