Hello development folks,
while waiting for ${things} to finish here, I went through the Pakfire add-on list and came across some packages which - as far as I know - ...
(a) ... are not regularly maintained by a member of the IPFire development team (b) ... do not seem to be frequently installed by our users (c) ... should not run on a firewall for security purposes, anyway
Among these are:
- Asterisk (13.18.5, upstream is currently on 18.0.0) - Icinga (1.11.4, upstream is currently on ~ 1.14.2 and 2.x.y, which comes with a bunch of dependencies such as a database, while Icinga 1.x was more or less a standalone system) - libsrtp (1.5.4, upstream is currently on 2.3.0) - OpenLDAP (2.4.49, upstream is currently on 2.4.55) - SANE (1.0.28, upstream is currently on 1.0.31, this should not be too hard, but I am not aware of IPFire users needing this) - SquidClamAV (since the overwhelming majority of web traffic is encrypted by now, I guess it makes little sense to ship this add-on anymore. Upstream seems to be unmaintained - most people are doing this via ICAP those days -, and this also arises the question why we need ClamAV anymore) - sslh (1.7a, upstream is currently on 1.21c) - transmission (2.94, upstream is currently on 3.00, but I do not observe a broader user group for this)
Are we able to drop those add-ons entirely? If yes, I will submit patches to do so. :-)
Thanks, and best regards, Peter Müller
Hello,
On 3 Nov 2020, at 10:13, Peter Müller peter.mueller@ipfire.org wrote:
Hello development folks,
while waiting for ${things} to finish here, I went through the Pakfire add-on list and came across some packages which - as far as I know - ...
(a) ... are not regularly maintained by a member of the IPFire development team (b) ... do not seem to be frequently installed by our users
Where did you get that data from?
(c) ... should not run on a firewall for security purposes, anyway
That probably is outside of the scope of this discussion.
Among these are:
- Asterisk (13.18.5, upstream is currently on 18.0.0)
13 is an LTS release and still actively maintained. An update could be done easily and should not break anything.
- Icinga (1.11.4, upstream is currently on ~ 1.14.2 and 2.x.y, which comes with a bunch of dependencies such as a database, while Icinga 1.x was more or less a standalone system)
Same here. This could easily be updated.
- libsrtp (1.5.4, upstream is currently on 2.3.0)
This is a dependency of Asterisk.
- OpenLDAP (2.4.49, upstream is currently on 2.4.55)
We use this library to connect the web proxy to LDAP servers and domain controllers.
There is no point in dropping that functionality.
OpenLDAP has had some licensing issues with Berkeley DB recently. Oracle has changed the license and therefore OpenLDAP could not use libdb 6 or newer. They wrote their own implementation of a fast key-value store which is a much better backend for LDAP now.
- SANE (1.0.28, upstream is currently on 1.0.31, this should not be too hard, but I am not aware of IPFire users needing this)
I am not using it and I think there are not any devices supported any more. Thoughts anyone?
- SquidClamAV (since the overwhelming majority of web traffic is encrypted by now, I guess it makes little sense to ship this add-on anymore. Upstream seems to be unmaintained - most people are doing this via ICAP those days -, and this also arises the question why we need ClamAV anymore)
Just because *some* traffic is encrypted does not mean that we should weaken any defences in other areas.
- sslh (1.7a, upstream is currently on 1.21c)
Is there any reason why this cannot be updated?
- transmission (2.94, upstream is currently on 3.00, but I do not observe a broader user group for this)
We do not have any hard figures on this and 2.94 is a recent release. It is in fact the one before 3.00.
Are we able to drop those add-ons entirely? If yes, I will submit patches to do so. :-)
I disagree with dropping add-ons which you do not use specifically. If I had my way, I would drop loads of other features that I am personally not using, but that is not exactly what we want to achieve.
IPFire should have a broad audience. People use different features and some people don’t use some features at all. As long as someone is willing to maintain a package and it is being supported upstream, I do not see why we should drop it.
Best, -Michael
Thanks, and best regards, Peter Müller