From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Proposal for dropping some add-ons Date: Tue, 03 Nov 2020 11:03:44 +0000 Message-ID: <4DE18DF2-1E4A-49B2-8FEA-1582803AF898@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5971442096353187872==" List-Id: --===============5971442096353187872== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 3 Nov 2020, at 10:13, Peter M=C3=BCller wro= te: >=20 > Hello development folks, >=20 > 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 - ... >=20 > (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: >=20 > - 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 e= asily 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 contr= ollers. 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. Th= ey wrote their own implementation of a fast key-value store which is a much b= etter backend for LDAP now. > - SANE (1.0.28, upstream is currently on 1.0.31, this should not be too har= d, 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. T= houghts 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. Upst= ream seems > to be unmaintained - most people are doing this via ICAP thos= e 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 i= n fact the one before 3.00. > Are we able to drop those add-ons entirely? If yes, I will submit patches t= o 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 p= eople don=E2=80=99t use some features at all. As long as someone is willing t= o maintain a package and it is being supported upstream, I do not see why we = should drop it. Best, -Michael >=20 > Thanks, and best regards, > Peter M=C3=BCller=20 --===============5971442096353187872==--