From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] urlfilter: Remove bundled Toulouse blacklist
Date: Sun, 27 Sep 2026 12:44:53 +0200 [thread overview]
Message-ID: <f21e71cc-7add-49e8-bdd8-788187ac3e51@ipfire.org> (raw)
In-Reply-To: <e88a2dd8-20b6-4422-885c-69e2f59b1451@orange.fr>
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.
On 07/09/2026 18:51, p27m wrote:
> Hello Michael,
>
> Yes, I Build it and install master ISO (CU204) on my test virtual machine.
>
> SquidGuard starts without errors when the blacklist directory is empty (the patch preserves the custom list).
> Naturally, no category-based filtering takes place until a blacklist has been downloaded.
>
> I also ran a test using only a custom blacklist.
> In this case, SquidGuard starts normally, and the custom domain is correctly blocked.
>
> This point was documented in comment #13 of bug 13969:
> https://bugzilla.ipfire.org/show_bug.cgi?id=13969#c13
>
> Thus, removing the default blacklist does not prevent URLFilter/SquidGuard from starting or functioning.
> The user can simply download or restore a blacklist later, or use only the custom blacklist.
>
> Best regards,
>
> Philippe
>
> Le 07/09/2026 à 17:22, Michael Tremer a écrit :
>> Hello Phil,
>>
>> Yes, this makes sense so far. But what actually happens when squidGuard is being started with nothing? I remember that this list has been treated as a dummy. Did you test this case too?
>>
>> -Michael
>>
>>> On 29 Aug 2026, at 16:56, p27m <p27m@orange.fr> wrote:
>>>
>>> Hi Michael,
>>>
>>> Thank you for your reply.
>>>
>>> The problem described in the bug report is actually quite simple.
>>>
>>> Currently, the blacklist included in the IPFire repository and installed with IPFire dates from June 15, 2005, so it is now obsolete.
>>> Since March 2026, the University of Toulouse has changed some directories in its blacklist into symbolic links.
>>> Therefore, when restoring a backup containing a blacklist downloaded after this change, `tar` can fail because symbolic links cannot replace existing directories. As a result, the backup restoration fails.
>>>
>>> @adolf previously added a fix to `backup.pl` which removes the existing contents of `/var/ipfire/urlfilter/blacklists/` before extracting the backup.
>>>
>>> However, I recently discovered that the problem could still occur when restoring a backup from a backup ISO.
>>>
>>> For this reason, I thought that the simplest solution, and the best way to avoid similar problems in the future, would be to remove the obsolete blacklist archive from the installation.
>>>
>>> This patch does not prevent URLFilter from working without an installed blacklist. It also ensures that the old blacklist shipped with IPFire cannot interfere with restoring a newer blacklist from a backup.
>>>
>>> I have tested the patch with upgrades, fresh ISO installations, and restoration of backups containing both the Toulouse blacklist and the IPFire DBL blacklist.
>>>
>>> Best regards,
>>>
>>> Philippe
>>>
>>> Le 29/08/2026 à 17:31, Michael Tremer a écrit :
>>>> Thank you very much for this patch.
>>>>
>>>> I could not quite figure out what you want to achieve with this change. Is this data being shipped causing some problems? The bug report did not give me the information I was looking for either.
>>>>
>>>> All the best,
>>>> -Michael
>>
>
next prev parent reply other threads:[~2026-09-27 10:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 9:16 Philippe SCARSELLI
2026-08-29 15:31 ` Michael Tremer
2026-08-29 15:56 ` p27m
2026-09-07 15:22 ` Michael Tremer
2026-09-07 16:51 ` p27m
2026-09-27 10:44 ` Adolf Belka [this message]
2026-09-27 12:17 ` p27m
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f21e71cc-7add-49e8-bdd8-788187ac3e51@ipfire.org \
--to=adolf.belka@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox