IDS/IPS and antivirus on 2.1 release
-
DO NOT UPGRADE UNLESS IT BREAKS - *nix Philosophy No. 2
As far as the broken packages with frequent updates of pfSense base are concerned (which is preferred by most of the non-*nix users these days), I would like to remind *nix philosophy that do not upgrade if it does not break. However for snapshot releases you may need to do so, but before check the changelog. FYI, I am still on July 18 snapshot because it is working for my own needs. ;-)
Not sure that applies in a security relevant context. Usually upgrades mean bug fixes, and bugs are potential exploits. So as far as security relevant software goes, I'd like to be on the latest patch level of every single component of the system, as far as anyhow possible.
I'm sure a few year old version would seem to work just as trouble free, until such point that someone uses a bug for an exploit and hacks the system.
This is a very different scenario as a desktop OS and a word processor, where one can say: "If you could write with it a letter yesterday, you can write one tomorrow, so why bother upgrading and risking potentially incompatible changes?"SEPARATION OF PACKAGES - A Suggestion
[…]I suggest the developers of pfSense to separate the active packages from not-maintained packages to avoid confusion that it is not the problem with pfSense developers' part when the package breaks.That would be a good step. It's essentially impossible to discern which package is acting out "Sleeping Beauty" and rests for the next 100 years, and which ones are being maintained.
-
The package system already has a way to deal with this. The files with the list of possible packages can have min and max pfSense version specified. When 2.1 came out (requiring pbi installer files) lots of packages had their max version set so they would not appear for install on 2.1. These limits have been removed as packages got a pbi available and could install on 2.1. Similarly the min version protects new packages from being installed on 1.2.3 (or very new packages with pbi only, that won't install on 2.0.n).
Obviously, just because a pbi is built, it doesn't mean the package is guaranteed to work on 2.1 - someone also has to test it! So there can easily be packages listed for 2.1 that don't work so well :(
If different things need to be done in configuring a package on different pfSense versions then the code in the package PHP tests the pfSense version and does different stuff accordingly. This is now quite routine, and many packages have a "standard" bit of code at the top of their PHP that sets various "environment variables" depending on the run-time pfSense version. Subsequent code substitutes the variables as needed.IMHO, the package system is a great thing, and just needs:
a) More package maintainers to care for their package and are willing to learn how packages are implemented and do their code in a reasonably common manner.
b) Fixing up the alpha, beta, release, stable… package status - first make an agreed list of status words, someone to assess how robust each package is now, update the status, then in consultation with package maintainers, keep the status up-to-date. (and maybe add a filter to the package list display to just show packages from a selected status and above)
c) Add more package doco and release notes (and future plans even) on the WiKi (pointed to from the package install list) so that users have an easy trail to follow to know what is going on with a package.I can understand that for the BSD Perimeter/Electric Sheep Fencing guys, they need to be very careful about a package having a status that implies it is "officially supported" in some way. They need to decide if they are happy to have a package status that means "really great and won't ever break your base system, it will be supported like the base system". Otherwise the set of package status words needs to have a "best" status that does not imply this...
It all requires willing and capable volunteers.
-
DO NOT UPGRADE UNLESS IT BREAKS - *nix Philosophy No. 2
As far as the broken packages with frequent updates of pfSense base are concerned (which is preferred by most of the non-*nix users these days), I would like to remind *nix philosophy that do not upgrade if it does not break. However for snapshot releases you may need to do so, but before check the changelog. FYI, I am still on July 18 snapshot because it is working for my own needs. ;-)
Not sure that applies in a security relevant context. Usually upgrades mean bug fixes, and bugs are potential exploits. So as far as security relevant software goes, I'd like to be on the latest patch level of every single component of the system, as far as anyhow possible.
AFAIK, a bug means the system breaks, no matter to what extent. So bug fix is the part of the broken system. I do not deny that.
I'm sure a few year old version would seem to work just as trouble free, until such point that someone uses a bug for an exploit and hacks the system.
New exploits can happen to any system any time because penetrators (particularly with APT guys) use newer methods than the newest that you think of! ;-) So there is always a risk of new exploits.
In some places I am using firewalls-cum-routers that runs on a single floppy disk on a very low-end machine, working without any problem since the last century. So it depends on sys-/net-admin.
This is a very different scenario as a desktop OS and a word processor, where one can say: "If you could write with it a letter yesterday, you can write one tomorrow, so why bother upgrading and risking potentially incompatible changes?
Mostly frequent upgrades through upgrade managers is the problem with the one who uses sophisticated Xwindows systems, particularly in desktops. What I have seen is most of the computer users these days choose to upgrade stuffs automagically without knowing what they are doing to the system nor reading any changelogs or security advisory. They do it just because something is automagic!
I have seen even on the *nix systems like Debian, CentOS that sometimes things break because of incompatibility of libraries after an update which would have been working flawlessly earlier. Maybe that is the reason, pfSense team has chosen pbi which delivers both packages plus dependency libraries like in NixOS.
However, I am for upgrading for security vulnerabilities plus feature needs, not because it just says that there is something new in the market. If it works and safe, there is no need to upgrade. It's like marriage. ;-)
Ed Hillary was asked why he climbed Mt. Everest, his reply was "Because it is there." It does not mean that everyone has to climb Mt. Everest because it is there. Same applies to software upgrades, it is not always necessary to upgrade just because it is there!