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 4j0J9S2KxPz32dD for ; Wed, 07 Oct 2026 16:14:36 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (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 4j0J9N6m9nz2xLl for ; Wed, 07 Oct 2026 16:14:32 +0000 (UTC) Received: from out.smtpout.orange.fr (out-11.smtpout.orange.fr [193.252.22.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.smtpout.orange.fr", Issuer "DigiCert Global G2 TLS RSA SHA256 2020 CA1" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4j0J9M2ZbgzBn for ; Wed, 07 Oct 2026 16:14:31 +0000 (UTC) Authentication-Results: mail01.ipfire.org; dkim=pass header.d=orange.fr header.s=t20230301 header.b=NAD9dn8O; spf=pass (mail01.ipfire.org: domain of p27m@orange.fr designates 193.252.22.11 as permitted sender) smtp.mailfrom=p27m@orange.fr; dmarc=pass (policy=quarantine) header.from=orange.fr ARC-Seal: i=1; a=rsa-sha256; d=lists.ipfire.org; s=202003rsa; cv=none; t=1791389671; b=lFMwZNGYmmcBV8gGfy3VzozRLZ0f3FDklghwJunA3bk4KtU4ANPKFOgijg8gRC/Gvd7yIF +e1KTqLbsrcegGcqvm3Yxs52mEa40C5IDxtZdQ8VLJQwGV7gOs39AM57FJ0WL6uADGZP9E hzxlw4BjMG9eYnevi8geo5/AKE25gYPkDViumQZ6m2QKWepog8daxJY0Ki88jDsPjaKkLT CmPkGdjzlQTinjEmcJU1y7hwsZOksReT05kWqtKo7fjvvfE1dFyBhijGN9F314yZxnldaF pVXp/qkKi0qP0bH+DrZMR5y+AGtsKzuTodElpE/Hw5XgLEkhK+qpnt5BHRO/TA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.ipfire.org; s=202003rsa; t=1791389671; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yvvczBvtEDNzvWLiRPJpVDPJHLpJgYzC/NfvmwaHtow=; b=L/lLJkW2pjaKol8sY4XMCtkyF3phDK2sfWMZm2nBFDM5qsPujZWUVHKq+6SfKkHOhIO60w hde+2N1DGgQ7Il0RkM/vcY6kQQQ2+tR7TDaZ39TdzL3jnFckXtaR8iktCZ4NtRtswps1uC SQQbWSvaBmmF2/4YrI7HDBTxETgnhd6/F+zEOja/x1m/tRg5lLs661M5DOEykgXgKXs6UK EOsmczlEgcwTCfBAQNYzdOsODX/kU1kMncLg67LIbvksslvgtQw0jxtqWjz5FzxnEDS5yw rIyuNb6mEoT5onBRj2F2pc4LdyXuWAriOXrO+hY9HmQcPANhyyIZ+8m0LDd4Ew== ARC-Authentication-Results: i=1; mail01.ipfire.org; dkim=pass header.d=orange.fr header.s=t20230301 header.b=NAD9dn8O; spf=pass (mail01.ipfire.org: domain of p27m@orange.fr designates 193.252.22.11 as permitted sender) smtp.mailfrom=p27m@orange.fr; dmarc=pass (policy=quarantine) header.from=orange.fr Received: from [192.168.20.32] ([176.146.212.228]) by smtp.orange.fr with ESMTPSA id EUHmxERMejXAcEUHmxknYw; Wed, 07 Oct 2026 18:14:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1791389670; bh=yvvczBvtEDNzvWLiRPJpVDPJHLpJgYzC/NfvmwaHtow=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=NAD9dn8OVGJWi0aSdKmxdh4xL0gJACSpzcBkdB4of4XOXlqbR3ZC5YWd9vrhtiQHf HRMgFV5DFINSrZhJrU1nMiJTAQNpGswI5381t5SPR5Ygho/9Es8dHJkjBseSfQUsYX vsIGD6kSf+aMXUHUIyX/ZqoyhTWBdyf03Dhvepkw39yt5gHPFRoy0lXHZc7ONJ3Aj9 TjLlTmC6n/vwNqfP2fXm6ozV2IHs0Q/Pg3+E+wE5+ynuk5DTC6fpTSVKXEDfnFPlWy mpHWOMCB5E3cjBScXG4SKLVk+rGAjTsMj495XwpoKRxg9b5u+33Q4YTcJ/XKFkoYrX tZzDJtOFxeH5w== X-ME-Helo: [192.168.20.32] X-ME-Auth: cDI3bUBvcmFuZ2UuZnI= X-ME-Date: Wed, 07 Oct 2026 18:14:30 +0200 X-ME-IP: 176.146.212.228 Message-ID: Date: Wed, 7 Oct 2026 18:14:29 +0200 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] urlfilter: Remove bundled Toulouse blacklist To: development@lists.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> <4FD17803-1E9B-41C4-A51B-CCE5F3BC92D1@ipfire.org> <77b98f70-5ca1-44bf-9e51-2501df58cbfc@orange.fr> Content-Language: fr, en-US From: p27m In-Reply-To: <77b98f70-5ca1-44bf-9e51-2501df58cbfc@orange.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: mail01.haj.ipfire.org X-Rspamd-Queue-Id: 4j0J9M2ZbgzBn X-Rspamd-Action: no action X-Spamd-Result: default: False [-3.90 / 11.00]; BAYES_HAM(-3.00)[100.00%]; DMARC_POLICY_ALLOW(-0.50)[orange.fr,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:193.252.22.0/25]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.10)[orange.fr:s=t20230301]; R_DKIM_ALIGNED(-0.10)[strict]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.10)[smtp-in.orange.fr]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[orange.fr]; RCPT_COUNT_ONE(0.00)[1]; ARC_SIGNED(0.00)[lists.ipfire.org:s=202003rsa:i=1]; FREEMAIL_FROM(0.00)[orange.fr]; IP_REPUTATION_SPAM(0.00)[asn: 3215(0.00), country: FR(0.00), ip: 193.252.22.11(0.00)]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[orange.fr:+]; RECEIVED_SPAMHAUS_PBL(0.00)[176.146.212.228:received]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[193.252.22.11:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:3215, ipnet:193.252.20.0/22, country:FR]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_REPUTATION(0.00)[0]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[orange.fr:dkim] Hi Michael, Following your suggestion of removing the URL Filter blacklists from the backup handled by |backup.cgi|, I tested the backup and restore functionality available directly through |urlfilter.cgi|. This backup mechanism is actually a useful option for backing up and restoring the existing URL Filter configuration, including both the settings and the blacklists. However, I found another issue. If a backup is made with a recent Toulouse blacklist and then restored on an IPFire installation that still contains the original 2015 Toulouse blacklist shipped with IPFire, the following entries from the backup are symlinks: * |ads -> publicite| * |aggressive -> agressif| * |drugs -> drogue| * |mail -> forums| * |porn -> adult| * |proxy -> redirector| * |violence -> agressif| These entries are not restored because the corresponding directories already exist in the original blacklist. The old directories are therefore kept instead. As a result, the restored installation ends up with a mixture of old and new blacklist data. This test leads me to the conclusion that removing the obsolete Toulouse blacklist from the initial IPFire installation image remains one of the cleanest options. It prevents the old data from interfering with a later restoration of a more recent blacklist. Of course, I leave the final choice of implementation to you. Regards, Philippe Le 29/09/2026 à 17:37, p27m a écrit : > Hi , > > “Clear the directory before the lists are being restored” is actually > already what Adolf implemented in |backup.pl| in CU203 to fix this bug. > > However, this is not done in |installer/hw.c|, as discussed in Bugzilla: > https://bugzilla.ipfire.org/show_bug.cgi?id=13969#c5 > > So clearing the directory before restoring the lists there would > indeed be another approach that should work. > > My intention in proposing this patch was simply to help and avoid > additional work, rather than to argue about which solution is the best > one. > > I think there are several possible ways to address the issue, so I > will leave it to you to choose and implement the approach that you > consider most appropriate for IPFire. > > Regards, > > Philippe > > > Le 29/09/2026 à 17:10, Michael Tremer a écrit : >> 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: >>> >>> Hi Michael, >>> >>> 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. >>> >>> In fact, the IPFire DBL list also contains the following directories: >>> - ads >>> - porn >>> - violence >>> >>> These are symlinks in the current Toulouse `blacklists.tar.gz`: >>> - ads -> publicite >>> - porn -> adult >>> - violence -> agressif >>> >>> 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. >>> >>> Regards, >>> -- >>> Philippe >>> >>> Le 29/09/2026 à 15:19, Michael Tremer a écrit : >>>> Hello, >>>> >>>> I generally do agree with dropping the old data. It is more than >>>> obsolete, but that leaves us with some new problems: >>>> >>>> * 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. >>>> >>>> * 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. >>>> >>>> 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. >>>> >>>> Does that sound good to you, too? >>>> >>>> -Michael >> > >