Re: [PATCH] urlfilter: Remove bundled Toulouse blacklist

[Michael Tremer <michael.tremer@ipfire.org>]

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 <p27m@orange.fr> wrote:
> 
> Hi Adolf,
> 
> Thank you for following up on this.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> I also wonder whether it makes sense to continue installing a blocklist which may become obsolete again relatively quickly, or potentially disappear altogether.
> 
> There is already a blocklist maintained by IPFire at:
> 
> https://dbl.ipfire.org/lists/squidguard.tar.gz
> 
> It might therefore make more sense to use this list as the bundled default instead.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Regards,
> 
> Philippe
> 
> 
> Le 27/09/2026 à 12:44, Adolf Belka a écrit :
>> Hi All,
>> 
>> I am following up on this as it has not had any follow-up for a while..
>> 
>> 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.
>> 
>> 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.
>> 
>> Regards,
>> 
>> Adolf.
>