Development August 2024

development@lists.ipfire.org

9 participants
57 discussions

Feedback on WG
by Adolf Belka 07 Sep '24

07 Sep '24

Hi Michael, Sorry for the delay with feedback on the WG testing. I was a bit tied up with DIY stuff in the house. By manually importing the WG config file created I was able to successfully connect from my laptop to my IPFire vm system. The WUI showed connected. The config file had my allowed subnets set as 192.168.200.0/255.255.255.0 which is the green subnet on my vm system. However trying ping over the WG tunnel gave failures for the IP of the vm machine, green1, and also for the green interface of the vm IPFire. Trying to ping with the FQDN for the green1 system resulted in no resolving of green1's FQDN to a local IP but tried to send it to my main red interface with my ISP. So something appears to be missing or incorrect with the routing but not sure what. Minor points on the WUI. When disconnected the status section that is coloured red is huge and the space for the remark is very small but when connected then the status space is large enough to have the connected status word, giving much more room for the remark. When the WG config file is created and you have the page with the QR code, there is also a message about the WG config file only being shown this one time as it contains private key material. The message is fine but the heading for the message is "Oops, something went wrong...". It should really be something like "Information Note" or equivalent as it is not an actual error message. See the screenshots attached. Regards, Adolf.

2 16

Question concerning the language dependent handling of values in our config files
by Jonatan Schlag 31 Aug '24

31 Aug '24

Hi list, I currently have a slight problem and need advice on how to solve it. We read and write our config (for example /var/ipfire/ethernet/settings) in programms in different languages. In the C code, we allow all characters: https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/libsmooth/varval.c;h=… In Bash Code, we only allow some characters: https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/scripts/readhash;h=bf… So the new function https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/fu… warns about values which are invalid and ignores those. The old readhash script has not done this. But now we are in the unfortunate situation that: RED_DESCRIPTION='"pci: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09)"' is a valid config line in C code but an invalid line in Bash code. The question is: How can we solve this? Should I add code to the C library to remove all invalid characters from the values and write the value then? This might lead to problems, as we do not write the value the program has provided. So happy to receive your input on this matter. Jonatan

1 0

Failure to build clamav due to rust reversion
by Adolf Belka 30 Aug '24

30 Aug '24

Hi Michael & Matthias, I just re-ran my build after the removal of the coreutils patch. The build went past coreutils with no problem. However it has then failed at clamav (1.4.0) with the message error: package `home v0.5.9` cannot be built because it requires rustc 1.70.0 or newer, while the currently active rustc version is 1.67.0 Either upgrade to rustc 1.70.0 or newer, or use cargo update -p home(a)0.5.9 --precise ver where `ver` is the latest version of `home` supporting rustc 1.67.0 Rust was reverted back to 1.67.0 due to problems with building ruby for aarch64 and riscv64. https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=33ee3958de834f7eb686fb5… So until rust has the fix for building ruby for aarch64 and riscv64 then it looks like there needs to be a limit set to the version of rust-home to 0.5.3, which is the version that we have with rust-1.67.0 Unless of course I have not understood the root cause of this problem, which definitely could be the case. Regards, Adolf.

3 7

Re: The unshared changes give a problem with build after doing git pull on next
by Michael Tremer 30 Aug '24

30 Aug '24

Hello, > On 8 Aug 2024, at 13:06, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote: > > Hi, > > ok - please don't laugh. > > I did something completely different... > > I added the following to 'make.sh': > > ***SNIP*** > diff --git a/make.sh b/make.sh > index 922fc4b4c..212256ab1 100755 > --- a/make.sh > +++ b/make.sh > @@ -662,6 +662,11 @@ execute() { > # If unshare is asked to terminate, terminate all child processes > "--kill-child" > ) > + > +mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc > + > +mount --make-rslave ${BUILD_DIR}/proc > + > fi I don’t know why this would fix anything. Could you once again try to swap the slave/private parameters of the —-propagation option for both calls of unshare? Also: Why is this working on my freshly installed system? > > while [ $# -gt 0 ]; do > ***SNAP*** > > No 'invalid argument' error anymore. > > I don't know why - but with this patch the build is running... > > Any comments? > > Best > Matthias > > On 06.08.2024 17:40, Michael Tremer wrote: >> Hello, >> >> We should not touch the mount propagation of the host’s namespace. >> >> Instead, we should create our own mount namespace and that should be private. >> >> You can however try to see what happens when you add —-propagation=slave to the first unshare command. >> >> I just installed the plain Ubuntu Server, installed git, checkout out the repository, downloaded the toolchain and ran the build. >> >> -Michael >> >>> On 3 Aug 2024, at 12:22, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote: >>> >>> On 03.08.2024 10:54, Michael Tremer wrote: >>>> Hello Matthias, >>> >>> Hi Michael, >>> >>> just looked through https://man7.org/linux/man-pages/man1/unshare.1.html >>> and ran 'findmnt -o+PROPAGATION' (see attachment). >>> >>> I don't know if this could help but does this differ from your test >>> installation? >>> >>> Best >>> Matthias >>> >>>>> On 3 Aug 2024, at 08:47, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote: >>>>> >>>>> Hi Michael, >>>>> >>>>> [shortened some stuff] >>>>> >>>>> ... >>>>> >>>>>>>>> >>>>>>>>> Being curious I tried to build 'next', but I always get the same error: >>>>>>>>> >>>>>>>>> ***SNIP*** >>>>>>>>> root@Devel64-1: /git/ipfire-2.x # ./make.sh build >>>>>>>>> Packaged toolchain compilation >>>>>>>>> Building IPFire >>>>>>>>> stage2 >>>>>>>>> Jul 26 13:32:59: Building stage2 unshare: cannot change >>>>>>>>> /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument >>>>> >>>>>>>> ... >>>>> >>>>>> It looks like you can simply update the kernel staying on the same release: >>>>>> >>>>>> https://ubuntu.com/security/livepatch/docs/livepatch/reference/kernels >>>>>> >>>>>> For 22.04 LTS, there is a Linux 6.8 image available. >>>>>> >>>>>> Could you check that and confirm that it fixes the mount propagation problem? >>>>> >>>>> Done. >>>>> >>>>> Current state is as follows: >>>>> >>>>> ***SNIP*** >>>>> ... >>>>> root@Devel64-1: /git/ipfire-2.x # lsb_release -a >>>>> No LSB modules are available. >>>>> Distributor ID: Ubuntu >>>>> Description: Ubuntu 22.04.4 LTS >>>>> Release: 22.04 >>>>> Codename: jammy >>>>> ... >>>>> root@Devel64-1: /git/ipfire-2.x # uname -mrs >>>>> Linux 6.8.0-39-generic x86_64 >>>>> ... >>>>> ***SNAP*** >>>>> >>>>> But when I try to build 'next' I get exactly the same error as >>>>> before: >>>>> >>>>> ***SNIP*** >>>>> root@Devel64-1: /git/ipfire-2.x # ./make.sh build >>>>> Packaged toolchain compilation >>>>> Building IPFire >>>>> stage2 >>>>> Aug 2 21:21:15: Building stage2 unshare: cannot change >>>>> /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument >>>> >>>> Ah, this is good information. So it is not the kernel, it rather is Ubuntu handling something differently. >>>> >>>> I will have a look at this and get back to you. >>>> >>>>> ERROR: Downloading stage2 >>>>> [ FAIL ] >>>>> Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if >>>>> applicable [ FAIL ] >>>>> ***SNAP*** >>>>> >>>>> Being curious, I commented line line 633 in 'make.sh' >>>>> ("--mount-proc=${BUILD_DIR}/proc") => Building starts but fails during >>>>> 'glib 2.77.0': >>>>> >>>>> ***SNIP*** >>>>> ... >>>>> glib (2.77.0) >>>>> [ 1:14 ][0/1011] >>>>> >>>>> [951/1374] Compiling C object gio/gio.p/gio-tool-tree.c.o >>>>> [952/1374] Linking target gio/gio >>>>> [953/1374] Compiling C object >>>>> gio/gio-querymodules.p/gio-querymodules.c.o >>>>> [954/1374] Linking target gio/gio-querymodules >>>>> [955/1374] Compiling C object gio/gresource.p/gresource-tool.c.o >>>>> [956/1374] Compiling C object >>>>> gio/glib-compile-schemas.p/.._subprojects_gvdb_gvdb_gvdb-reader.c.o >>>>> [957/1374] Linking target gio/gresource >>>>> [958/1374] Compiling C object >>>>> gio/glib-compile-schemas.p/.._subprojects_gvdb_gvdb_gvdb-builder.c.o >>>>> [959/1374] Compiling C object >>>>> gio/glib-compile-resources.p/.._subprojects_gvdb_gvdb_gvdb-reader.c.o >>>>> [960/1374] Compiling C object >>>>> gio/glib-compile-resources.p/.._subprojects_gvdb_gvdb_gvdb-builder.c.o >>>>> [961/1374] Compiling C object >>>>> gio/glib-compile-resources.p/glib-compile-resources.c.o >>>>> [962/1374] Linking target gio/glib-compile-resources >>>>> [963/1374] Compiling C object >>>>> gio/tests/modules/libtestmodulea.so.p/test-module-a.c.o >>>>> [964/1374] Compiling C object gio/gapplication.p/gapplication-tool.c.o >>>>> [965/1374] Compiling C object gio/gsettings.p/gsettings-tool.c.o >>>>> [966/1374] Linking target gio/tests/modules/libtestmodulea.so >>>>> [967/1374] Generating gio/tests/plugin-resources.c with a custom command >>>>> FAILED: gio/tests/plugin-resources.c >>>>> /usr/src/glib-2.77.0/builddir/gio/glib-compile-resources >>>>> --compiler=gcc --target=gio/tests/plugin-resources.c --sour >>>>> cedir=/usr/src/glib-2.77.0/gio/tests --internal --generate-source >>>>> --c-name _g_plugin ../gio/tests/test4.gresource.xml >>>>> /usr/src/glib-2.77.0/builddir/gio/glib-compile-resources: error >>>>> while loading shared libraries: libgio-2.0.so.0: can >>>>> not open shared object file: No such file or directory >>>>> [968/1374] Linking target gio/gapplication >>>>> [969/1374] Compiling C object >>>>> gio/glib-compile-schemas.p/glib-compile-schemas.c.o >>>>> [970/1374] Linking target gio/gsettings >>>>> [971/1374] Compiling C object >>>>> gio/tests/modules/libtestmoduleb.so.p/test-module-b.c.o >>>>> [972/1374] Compiling C object >>>>> gio/tests/gdbus-overflow.p/gdbus-overflow.c.o >>>>> [973/1374] Compiling C object gio/gdbus.p/gdbus-tool.c.o >>>>> [974/1374] Compiling C object >>>>> gio/tests/gdbus-object-manager-example/libgdbus-example-objectmanager.so.p/meson-gener >>>>> ated_.._objectmanager-gen.c.o >>>>> ninja: build stopped: subcommand failed. >>>>> make: *** [glib:75: /usr/src/log/glib-2.77.0] Error 1 >>>>> make: Leaving directory '/usr/src/lfs' >>>>> >>>>> ERROR: Building glib >>>>> [ FAIL ] >>>>> Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if >>>>> applicable [ FAIL ] >>>>> ***SNAP*** >>>>> >>>>> Best >>>>> Matthias >>>> >> >> >> >

5 22

[PATCH] find-missing-libs.sh: Make file executable as rest in tools directory
by Adolf Belka 29 Aug '24

29 Aug '24

Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org> --- tools/find-missing-libs.sh | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 tools/find-missing-libs.sh diff --git a/tools/find-missing-libs.sh b/tools/find-missing-libs.sh old mode 100644 new mode 100755 -- 2.46.0

1 0

[PATCH 1/2] log.dat: Fix bug13762 - ssh logins not shown in system logs
by Adolf Belka 29 Aug '24

29 Aug '24

- With the update of openssh to version 9.8 in CU187 the daemon was changed from sshd to sshd-session. Therefore the log.dat no longer finds any info related to the logins. - This updates the section regex to look for both sshd and sshd-session. - Tested out on my vm system and confirmed to work. - This fix will make available all previous log info for sshd-session in the messages log as it continued to be stored, just could not be read by the WUI system log. Fixes: bug13762 Tested-by: Adolf Belka <adolf.belka(a)ipfire.org> Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org> --- html/cgi-bin/logs.cgi/log.dat | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/html/cgi-bin/logs.cgi/log.dat b/html/cgi-bin/logs.cgi/log.dat index 01c382a0d..41f81e99d 100644 --- a/html/cgi-bin/logs.cgi/log.dat +++ b/html/cgi-bin/logs.cgi/log.dat @@ -75,7 +75,7 @@ my %sections = ( 'samba' => '(nmbd|smbd|winbind)\[\d+\]:', 'suricata' => '(suricata: )', 'squid' => '(squid\[.*\]: |squid: )', - 'ssh' => '(sshd(?:$.*$)?\[.*\]: )', + 'ssh' => '(sshd(?:$.*$)?\[.*\]: |sshd-session(?:$.*$)?\[.*\]:)', 'unbound' => '(unbound: \[.*?\])(.*:.*$)', 'urlfilter bl' => '(installpackage\[urlfilter\]: )', 'wireless' => '(hostapd:|kernel: ath.*:|kernel: wifi[0-9]:)', -- 2.46.0

2 2

Feedback on CU188 update peculiarity
by Adolf Belka 29 Aug '24

29 Aug '24

Hi Michael, Something I noticed when I did the CU188 update. After finishing the update the Available Updates box says that Version: 2.27 -> 2.29 -- Release: 182 is available. If I then press the update button it repeats doing the CU188 update and at the end it again shows the same message about CU182 being available. Doing a reboot doesn't change it. The same message is there and if I press the button it repeats the CU188 update and then the same message again. Regards, Adolf.

2 3

[PATCH 1/3] borgbackup: Update to version 1.4.0
by Adolf Belka 27 Aug '24

27 Aug '24

- Update from version 1.2.7 to 1.4.0 - Update of rootfile - This version now requires libxxhash and can now work with python3-msgpack at version 1.0.8 so additional patch submissions combined with this one for implementation of libxxhash and for update og python3-msgpack. - Tested out changes on my vm testbed system and was able to access old repo info and fusemount the repo successfully and write a new backup. So everything I normally test is functioning. - Changelog 1.4.0 Compatibility notes: By default, borg 1.4 will behave quite similar to borg 1.2 (it was forked off from 1.2-maint branch at 1.2.7). - the slashdot hack: be careful not to accidentally give paths containing /./ to "borg create" if you do not want to trigger this feature (which strips the left part of the path from archived items). - BORG_EXIT_CODES=modern is a feature that borg script, wrapper and GUI authors may want to use to get more specific error and warning return codes from borg. In that case, of course they will need to make sure to correctly deal with these new codes, see the internals/frontends docs. Other changes: - vagrant: revive the buster64 box, RHEL8 has same glibc - tests: fix pytest_report_header, #8232 - docs: - mount: add examples using :: positional argument, #8255 - Installation: update Arch Linux repo name - update standalone binary section 1.4.0rc1 Fixes: - setup.py: fix import error reporting for cythonize import, #8208 - setup.py: detect noexec build fs issue, #8208 Other changes: - changed insufficiently reserved length for log message, #8152 - use Python 3.11.9, Cython 3.0.10 and PyInstaller 6.7.0 for binary builds - docs: - use python 3.9 in cygwin install docs, fixes #8196 - recreate: remove experimental status - github CI: fix PKG_CONFIG_PATH for openssl 3.0 - vagrant: - add a ubuntu noble (24.04) VM - drop buster VM, fixes #8171 1.4.0b2 Fixes: - check: fix return code for index entry value discrepancies - benchmark: inherit options --rsh --remote-path, #8099 - sdist: dynamically compute readme (long_description) - create: deal with EBUSY, #8123 - No need to use OpenSSL 3.0 on OpenBSD, use LibreSSL. - fix Ctrl-C / SIGINT behaviour for pyinstaller-made binaries, #8155 New features: - create: add the slashdot hack, update docs, #4685 - upgrade --check-tam: check manifest TAM auth, exit with rc=1 if there are issues. - upgrade --check-archives-tam: check archives TAM auth, exit with rc=1 if there are issues. Other changes: - improve acl_get / acl_set error handling, improved/added tests, #8125 - remove bundled lz4/zstd/xxhash code (require the respective libs/headers), simplify setup.py, remove support for all BORG_USE_BUNDLED_*=YES, #8094 - require Cython 3.0.3 at least (fixes py312 memory leak), #8133 - allow msgpack 1.0.8, #8133 - init: better borg key export instructions - init: remove compatibility warning for borg <=1.0.8 The warning refers to a compatibility issue not relevant any more since borg 1.0.9 (released 2016-12). - locate libacl via pkgconfig - scripts/make.py: move clean, build_man, build_usage to there, so we do not need to invoke setup.py directly, update docs - docs: - how to run the testsuite using the dist package - add non-root deployment strategy (systemd / capabilities) - simplify TAM-related upgrade docs using the new commands - vagrant: - use python 3.11.8 - use pyinstaller 6.5.0 - add xxhash for macOS, add libxxhash-dev for debianoid systems - use openindiana/hipster box 1.4.0b1 Fixes: - fix CommandError args, #8029 New features: - implement "borg version" (shows client and server version), #7829 Other changes: - better error msg for corrupted key data, #8016 - repository: give clean error msg for invalid nonce file, #7967 - check_can_create_repository: deal with PermissionErrors, #7016 - add ConnectionBrokenWithHint for BrokenPipeErrors and similar, #7016 - with-lock: catch exception, print error msg, #8022 - use cython 3.0.8 - modernize msgpack wrapper - docs: - add brew bundle instructions (macOS) - improve docs for borg with-lock, #8022 1.4.0a1 New features: - BORG_EXIT_CODES=modern: optional more specific return codes (for errors and warnings). The default value of this new environment variable is "legacy", which should result in a behaviour similar to borg 1.2 and older (only using rc 0, 1 and 2). "modern" exit codes are much more specific (see the internals/frontends docs). Fixes: - PATH: do not accept empty strings, #4221. This affects the cli interface of misc. commands (create, extract, diff, mount, ...) and they now will reject "" (empty string) given as a path. Other changes: - Python: require Python >= 3.9, drop support for 3.8, #6383 - Cython: require Cython >= 3.0, drop support for Cython 0.29.x, use 3str language level (default in cython3), #7978 - use pyinstaller 6.3.0 and python 3.11 for binary build, #7987 - msgpack: require >= 1.0.3, <= 1.0.7 - replace flake8 by ruff style/issue checker - tests: remove python-dateutil dependency - tests: move conftest.py to src/borg/testsuite, #6386 - move misc. config/metadata to pyproject.toml - vagrant: - use a freebsd 14 box, #6871 - use generic/openbsd7 box - use openssl 3 on macOS, FreeBSD, OpenBSD - remove ubuntu 20.04 "focal" box - remove debian 9 "stretch" box (remove stretch-based binary builds) - require recent setuptools and setuptools_scm - crypto: get rid of deprecated HMAC_* functions to avoid warnings. Instead, use hmac.digest from Python stdlib. Tested-by: Adolf Belka <adolf.belka(a)ipfire.org> Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org> --- config/rootfiles/packages/borgbackup | 16 ++++++++-------- lfs/borgbackup | 6 +++--- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/config/rootfiles/packages/borgbackup b/config/rootfiles/packages/borgbackup index eb08045c2..1f62a2d66 100644 --- a/config/rootfiles/packages/borgbackup +++ b/config/rootfiles/packages/borgbackup @@ -68,6 +68,7 @@ usr/lib/python3.10/site-packages/borg/testsuite/chunker.py usr/lib/python3.10/site-packages/borg/testsuite/chunker_pytest.py usr/lib/python3.10/site-packages/borg/testsuite/chunker_slow.py usr/lib/python3.10/site-packages/borg/testsuite/compress.py +usr/lib/python3.10/site-packages/borg/testsuite/conftest.py usr/lib/python3.10/site-packages/borg/testsuite/crypto.py usr/lib/python3.10/site-packages/borg/testsuite/efficient_collection_queue.py usr/lib/python3.10/site-packages/borg/testsuite/file_integrity.py @@ -92,11 +93,10 @@ usr/lib/python3.10/site-packages/borg/testsuite/xattr.py usr/lib/python3.10/site-packages/borg/upgrader.py usr/lib/python3.10/site-packages/borg/version.py usr/lib/python3.10/site-packages/borg/xattr.py -usr/lib/python3.10/site-packages/borgbackup-1.2.7-py3.10.egg-info -usr/lib/python3.10/site-packages/borgbackup-1.2.7-py3.10.egg-info/PKG-INFO -usr/lib/python3.10/site-packages/borgbackup-1.2.7-py3.10.egg-info/SOURCES.txt -usr/lib/python3.10/site-packages/borgbackup-1.2.7-py3.10.egg-info/dependency_links.txt -usr/lib/python3.10/site-packages/borgbackup-1.2.7-py3.10.egg-info/entry_points.txt -usr/lib/python3.10/site-packages/borgbackup-1.2.7-py3.10.egg-info/not-zip-safe -usr/lib/python3.10/site-packages/borgbackup-1.2.7-py3.10.egg-info/requires.txt -usr/lib/python3.10/site-packages/borgbackup-1.2.7-py3.10.egg-info/top_level.txt +usr/lib/python3.10/site-packages/borgbackup-1.4.0-py3.10.egg-info +usr/lib/python3.10/site-packages/borgbackup-1.4.0-py3.10.egg-info/PKG-INFO +usr/lib/python3.10/site-packages/borgbackup-1.4.0-py3.10.egg-info/SOURCES.txt +usr/lib/python3.10/site-packages/borgbackup-1.4.0-py3.10.egg-info/dependency_links.txt +usr/lib/python3.10/site-packages/borgbackup-1.4.0-py3.10.egg-info/entry_points.txt +usr/lib/python3.10/site-packages/borgbackup-1.4.0-py3.10.egg-info/requires.txt +usr/lib/python3.10/site-packages/borgbackup-1.4.0-py3.10.egg-info/top_level.txt diff --git a/lfs/borgbackup b/lfs/borgbackup index 7b77fd4bb..107e852a6 100644 --- a/lfs/borgbackup +++ b/lfs/borgbackup @@ -24,7 +24,7 @@ include Config -VER = 1.2.7 +VER = 1.4.0 SUMMARY = Deduplicating backup program with compression and authenticated encryption THISAPP = borgbackup-$(VER) @@ -33,7 +33,7 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = borgbackup -PAK_VER = 16 +PAK_VER = 17 DEPS = python3-msgpack python3-packaging python3-pyfuse3 # borgbackup only works with specific versions of python3-msgpack @@ -48,7 +48,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_BLAKE2 = 8d69f3e7890ee117e1fe2cdf6b92c548bc40b337de09850948150034fc4724bf05c51c852a268df2294e3657676920a1c663a421331fd6dba5fffa558429f11e +$(DL_FILE)_BLAKE2 = 06d4d67e211a3ab1bc6d7155cbce8205fb7408a1149e44c77b500af02c25e62a569e3eaf50c11916a2ff9adea47c5791febfb7d0c657d0b195e5c5bbbd33a7d7 install : $(TARGET) -- 2.46.0

1 2

Error message at end of build for a package that I have not touched
by Adolf Belka 27 Aug '24

27 Aug '24

Hi Michael, The last few build I have been doing I get the following message at the end of the build. Checking for missing rootfiles... 8812au-20210629-e6a0d1704ccd31145800ff5eb09ec2435a02f995-kmod-6.6.47-ipfire is missing a rootfile [ FAIL ] Not touched that file. It doesn't show up in the list of changed files so no problem with doing my builds for update patches. Regards, Adolf.

2 1

[PATCH] openssl: Update to version 3.3.1
by Adolf Belka 26 Aug '24

26 Aug '24

- Update from 3.3.0 to 3.3.1 - Update of rootfile not required - This version has 2 CVE fixes both of which are classified as Low Severity so looks like they can wait for CU189 - Changelog 3.3.1 * Fixed potential use after free after SSL_free_buffers() is called. The SSL_free_buffers function is used to free the internal OpenSSL buffer used when processing an incoming record from the network. The call is only expected to succeed if the buffer is not currently in use. However, two scenarios have been identified where the buffer is freed even when still in use. The first scenario occurs where a record header has been received from the network and processed by OpenSSL, but the full record body has not yet arrived. In this case calling SSL_free_buffers will succeed even though a record has only been partially processed and the buffer is still in use. The second scenario occurs where a full record containing application data has been received and processed by OpenSSL but the application has only read part of this data. Again a call to SSL_free_buffers will succeed even though the buffer is still in use. ([CVE-2024-4741]) * Fixed an issue where checking excessively long DSA keys or parameters may be very slow. Applications that use the functions EVP_PKEY_param_check() or EVP_PKEY_public_check() to check a DSA public key or DSA parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service. To resolve this issue DSA keys larger than OPENSSL_DSA_MAX_MODULUS_BITS will now fail the check immediately with a DSA_R_MODULUS_TOO_LARGE error reason. ([CVE-2024-4603]) * Improved EC/DSA nonce generation routines to avoid bias and timing side channel leaks. Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org> --- lfs/openssl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lfs/openssl b/lfs/openssl index 00b19b41a..d6333f7a4 100644 --- a/lfs/openssl +++ b/lfs/openssl @@ -24,7 +24,7 @@ include Config -VER = 3.3.0 +VER = 3.3.1 THISAPP = openssl-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -72,7 +72,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_BLAKE2 = c68efaf8aca87961f396e305acc767b56d651b9adf4fd2c9d9b5a3266e35da4b856c6ed34be47d656c782aade975f20317a6759913b33d29d7eb088e638fa501 +$(DL_FILE)_BLAKE2 = b09bbe94f49c33015fbcee5f578a20c0da33c289791bf33292170d5d3de44ea2e22144ee11067947aef2733e979c0fded875a4ec92d81468285837053447e68e install : $(TARGET) -- 2.46.0

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Development August 2024