Development June 2021

development@lists.ipfire.org

12 participants
93 discussions

Dropping Python 2
by Michael Tremer 02 Jun '21

02 Jun '21

Hello, I would like to talk about what has been discussed at the last developer conference call this week: Dropping Python 2 This version of Python has reached its end of life and will no longer receive any security fixes. Hence we need to get rid of it as soon as possible. However, there is lots of software that still depends on it which has to be migrated away first. There are at least the following packages: boost fetchmail fireinfo iotop ipaddr libxml2 libxslt newt nmap python python-clientform python-daemon python-distutils python-distutils-extra python-docutils python-feedparser python-inotify python-ipaddress python-m2crypto python-mechanize python-optional-src python-pyparsing python-rssdler python-setuptools python-six python-typing We also have the following scripts: config/ca-certificates/certdata2pem.py config/unbound/unbound-dhcp-leases-bridge Fireinfo is written by us and has a lot of C which will make it a little bit more difficult to migrate. We would also have to be very careful to not change any behaviour of the current implementation. The rest is probably either software that is entirely written in Python 2 or software that brings bindings for Python. The latter case is easy because we can either force it to build with Python 3 or we just disable the bindings. Ultimately we might need to keep Python around in the build system if there are other packages that rely on it. However, it would be great if we were able to remove it from the distribution very soon. Looking at his list, it does not seem to be too difficult. Would anyone be up to help and remove Python from any of those packages above? I would like to aim for Core Update 158 and remove as much stuff as possible - if we can everything - and then remove Python 2 in the update after that. If anyone has any custom scripts or applications, people will have some time to migrate away. Best, -Michael

3 43

[PATCH] configroot: prevent any Perl file within /var/ipfire/ from being owned by nobody
by Peter Müller 01 Jun '21

01 Jun '21

Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org> --- lfs/configroot | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lfs/configroot b/lfs/configroot index 2ab9cc29b..02b2883ba 100644 --- a/lfs/configroot +++ b/lfs/configroot @@ -1,7 +1,7 @@ ############################################################################### # # # IPFire.org - A linux based firewall # -# Copyright (C) 2007-2018 IPFire Team <info(a)ipfire.org> # +# Copyright (C) 2007-2021 IPFire Team <info(a)ipfire.org> # # # # This program is free software: you can redistribute it and/or modify # # it under the terms of the GNU General Public License as published by # @@ -169,7 +169,7 @@ $(TARGET) : # Configroot permissions chown -R nobody:nobody $(CONFIG_ROOT) chown root:root $(CONFIG_ROOT) - for i in backup/ header.pl general-functions.pl graphs.pl lang.pl addon-lang/ langs/ ; do \ + for i in backup/ *.pl addon-lang/ langs/ ; do \ chown -R root:root $(CONFIG_ROOT)/$$i; \ done chown -Rv root:root $(CONFIG_ROOT)/*/bin -- 2.26.2

1 0

Request: Port Mirroring (eg: netsniff-ng)
by Michelle Ako 01 Jun '21

01 Jun '21

Hello Team, First of all, I would like to thank you for your efforts in this amazing project. The resulting product is superb.. It would be greatly appreciated, as I have been trying to find a solution, for the possibility to integrate port mirroring capability within IPFire, perhaps like netsniff-ng. This is to feed internet traffic to a SIEM or NSM. If that ever becomes enabled, then a wazuh addon would be nice as well. I was thinking... IPFire connects to a SIEM/NSM (eg. Splunk, SecurityOnion, ...) via dedicated VPN tunnel (eg. OpenVPN) or Extra Physical Port. In order to feed internet traffic, port mirroring would be required (eg. netsniff-ng), While, wazuh would be a nice touch for security monitoring of the IPFire box itself. Internet <- IPFire -> VPN tunnel/physical port -> SIEM/NSM Hope this becomes a reality. Thank you again, you awesome people. Best regards, Michelle

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Development June 2021