From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4hvM7b448dz30Lt for ; Tue, 29 Sep 2026 15:10:51 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "YR2" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4hvM7X11Ngz2xHj for ; Tue, 29 Sep 2026 15:10:48 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4hvM7V2Dp5z60; Tue, 29 Sep 2026 15:10:46 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1790694646; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=46Am6F69loiH+8z1ql3WT2dNNJ8ghK3oXOkZMzuIYAM=; b=N5WqKXXGoLE4g6ZTt+7WiDCedNONjNGEzK0CiCUPhVJBQ5mAbtK8c0mbOqGPhRdkKV9yOq zPE9EqMDc7TVmeCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1790694646; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=46Am6F69loiH+8z1ql3WT2dNNJ8ghK3oXOkZMzuIYAM=; b=jyn8QHhtsM1I1uCJScyaPZEFraZCFDj++RVwIqvHqtMGmXK4XB8Sy+NNYijsdpacHv+k51 aG/xafKTZmsiZ3BNTjAEWCMwCCtcxGRWfnCjaaD6zw1FdXJyhLRE0R4ctWO/3uOrpbHsk0 vIBdt1DclnL5Ba96vpr3oVoS+9hzoQyH2MV+W5Oh915gRHlc1VYgVzgw6kJm8psxaL4Eq0 lxl59QepVXUrMZZVizNcPy+t1PpexePaCt6k96aMCdJ8ZXK4MF+armE4Fopp62vGn0Wfk4 dHvftn/HO57ZLFcFmny8S/RrdO4YWEuYojfC4c216ehq6zG9B+iOmiEXlt3CmQ== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: [PATCH] urlfilter: Remove bundled Toulouse blacklist From: Michael Tremer In-Reply-To: <706ad76b-d06e-4a85-975a-b53a2e39bf46@orange.fr> Date: Tue, 29 Sep 2026 16:10:45 +0100 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: <4FD17803-1E9B-41C4-A51B-CCE5F3BC92D1@ipfire.org> References: <20260827091639.4064898-1-p27m@orange.fr> <217EBED3-D400-4695-A345-816C7DD47207@ipfire.org> <6C039B7E-2BAF-45B7-9C87-A7D008EF3443@ipfire.org> <807301F9-A750-46D9-B614-2D4B1E99CA7A@ipfire.org> <706ad76b-d06e-4a85-975a-b53a2e39bf46@orange.fr> To: p27m Hello Philippe, Thanks for getting back so quickly. I suppose we will just have to clear the directory before the lists are = being restored. That should eliminate any problems after extraction. Where the list should be backed up at all is a completely different = story. We have been talking about this many times. Some people expect = only the configuration to be included in the backup and others expect a = full snapshot of the system. There is also the question of when the = backup is going to be restored: A couple of days later you will be okay = with a slightly out-of-date list; a couple of months later you will be = carrying a lot of data that is basically worthless. But we are doing the = same with the IPS rulesets and so on, so we should at least be = consistent. Best, -Michael > On 29 Sep 2026, at 16:07, p27m wrote: >=20 > Hi Michael, >=20 > Yes, I think this is a good functional solution, although it would = require a different implementation. > However, it does not address the original problem that led me to = propose this patch: the failure of a backup restore on fresh install = when the backup contains a recent Toulouse blacklist. >=20 > In fact, the IPFire DBL list also contains the following directories: > - ads > - porn > - violence >=20 > These are symlinks in the current Toulouse `blacklists.tar.gz`: > - ads -> publicite > - porn -> adult > - violence -> agressif >=20 > Therefore, if IPFire DBL is installed by default in new IPFire system, = restoring a backup containing a recent Toulouse blacklist could still = result in exactly the same directory/symlink conflict during the untar = restoration. >=20 > Regards, > -- > Philippe >=20 > Le 29/09/2026 =C3=A0 15:19, Michael Tremer a =C3=A9crit : >> Hello, >>=20 >> I generally do agree with dropping the old data. It is more than = obsolete, but that leaves us with some new problems: >>=20 >> * No data is available immediately. Users would have to go down to = the section of the page where they can select a list, enable the updates = and trigger a manual update. Only then they will be able to start the = URL Filter. This is a very convoluted process to enable a feature that = should be very easy to configure. >>=20 >> * If we shipped IPFire DBL by default, that would be a very sensible = solution actually. But then there is a danger that people will enable = the categories they want, enable URL Filter, but never enable the = automatic updates. If we enable the automatic updates ourselves, we = would run into the problem that a lot of IPFire instances all over the = world would be updating their blacklists although they are never being = used which will simply waste disk space and bandwidth. >>=20 >> So I think we need a change which is to ship IPFire DBL for new = installations, enable the auto-updates by default, but then only make = them actually work if URL filter is enabled at the top. That will solve = the problem in the latter case. >>=20 >> Does that sound good to you, too? >>=20 >> -Michael >=20