Proposal for dropping some add-ons

Proposal for dropping some add-ons

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]

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 

Re: Proposal for dropping some add-ons

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3247 bytes --]

Hello,

> On 3 Nov 2020, at 10:13, Peter Müller <peter.mueller(a)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