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 4hvJgD41R4z302F for ; Tue, 29 Sep 2026 13:19:36 +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 4hvJg86w21z2yZk for ; Tue, 29 Sep 2026 13:19:32 +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 4hvJg259Dnzld; Tue, 29 Sep 2026 13:19:26 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1790687967; 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=8tVqeTUOB+Pr7KsvHG3Z4r6FoZQPA38czaeQnQke1q0=; b=LRN8PpTRXynsB0KRMxpV5N4DPYyFM817oX1v3ayAlPMxb9EduOrEzkL5aLoCZxHLy/XlLx 3ZDnMYRvBwtF0uCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1790687967; 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=8tVqeTUOB+Pr7KsvHG3Z4r6FoZQPA38czaeQnQke1q0=; b=RMaiaC6setEe4BSaV23D7AUAVGfiUO1jxKWBGAX+sFAouLswVzBcO6b/vNnBviiop7m4ql lX6PQrlYkPh4cJUBzI0vveYPJvK0N7jXW9gQPp7RMWPuJk/WTONaKkSh1tK3TQnqPxhAPn makyB5g6zKbPJDaCFVFeckmhn+o0RC7dQc+jfOfg6agxSAiyQA20PcZdh7hRgYusXItVNb eHUJvc9oHYmeA2R5m+9i91BIlXlovlC2/VTCmT/FzCmB7SqBDq2bWJ/eD20vTA5T9/tRTM 8P4ztyKnyJ0IB8e2ekgJxbfqHyLcHpWHrvcFxh+3/HIngS+TTLNH1mgWdFY6NQ== 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: Date: Tue, 29 Sep 2026 14:19:25 +0100 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: <807301F9-A750-46D9-B614-2D4B1E99CA7A@ipfire.org> References: <20260827091639.4064898-1-p27m@orange.fr> <217EBED3-D400-4695-A345-816C7DD47207@ipfire.org> <6C039B7E-2BAF-45B7-9C87-A7D008EF3443@ipfire.org> To: p27m 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 > On 27 Sep 2026, at 13:17, p27m wrote: >=20 > Hi Adolf, >=20 > Thank you for following up on this. >=20 > The |blacklists.tar.gz| Toulouse blocklist currently present in the = IPFire repository dates back to 2015 and is one of the remaining parts = inherited from the old IPCop URL Filter add-on. It is not part of the = SquidGuard package itself. >=20 > Replacing |blacklists.tar.gz| with a newer version would indeed be a = viable solution to the current problem with directories being replaced = by symlinks. It should work without any code changes. >=20 > However, this would only be a workaround for the underlying problem. = There is no guarantee that the structure of the Toulouse blocklist will = not change again in the future, in which case the same problem could = reappear. >=20 > I also wonder whether it makes sense to continue installing a = blocklist which may become obsolete again relatively quickly, or = potentially disappear altogether. >=20 > There is already a blocklist maintained by IPFire at: >=20 > https://dbl.ipfire.org/lists/squidguard.tar.gz >=20 > It might therefore make more sense to use this list as the bundled = default instead. >=20 > However, this would not address the problem when restoring a backup = containing a Toulouse blocklist that was previously in use by the user. = The restore process could still encounter the same directory/symlink = conflict. >=20 > The solution I proposed is intended to address both aspects: removing = the obsolete bundled Toulouse list and making the restore process safe = in case an older Toulouse list is present in a backup. >=20 > That said, you are the experts on the IPFire codebase and its = long-term maintenance, so I will of course leave the final choice to = you. >=20 > Regards, >=20 > Philippe >=20 >=20 > Le 27/09/2026 =C3=A0 12:44, Adolf Belka a =C3=A9crit : >> Hi All, >>=20 >> I am following up on this as it has not had any follow-up for a = while.. >>=20 >> If there is a concern on the potential impact of not having any = bundled Toulouse blocklist in the URL Filter, an alternative would be to = have a newer version of the Toulouse Blocklist that includes the = symlinks approach that Toulouse started using earlier this year. >>=20 >> Would that be a viable approach? That would then keep the current = default status of having a blocklist defined but using one that has the = symlinks and therefore does not end up with the problem of trying to = create a symlink with the same name as an existing file. >>=20 >> Regards, >>=20 >> Adolf. >=20