From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4ZLwMG2N9bz331T for ; Mon, 24 Mar 2025 14:25:46 +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) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R10" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4ZLwMB0tyPz2yf1 for ; Mon, 24 Mar 2025 14:25:42 +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 4ZLwM92dCrz3W; Mon, 24 Mar 2025 14:25:41 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1742826341; 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=jLMCESPx3Tdvnt1U3Ng6f6MuasGhBDOHJMo1ld1PjpE=; b=A3e6a9wSPLCrDrCp5QmlXZugSf8znUNqezV10vxXkhIMGbRZc9RsQ/2hRZ1mWogGHQ+IU3 XeYKKO86qwV6ewCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1742826341; 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=jLMCESPx3Tdvnt1U3Ng6f6MuasGhBDOHJMo1ld1PjpE=; b=jCRmeCJe5ptUh2fSTEbYbRdZhBrdm97HibLW+uETWotdMOJKJncfxrAkx2ELvpsEBwZCri pQ5UfWVcn7L3CNtA9RzgVu2Ukv3hgvDc1WoT7pg3CA+H+cwQ69lCULs2Veafez5Zsg8uZo lk1/+bBE03s+8g/cMGi3z7VEC3BaNv3d6J2Keks9/I8enaYjzhmOWM2EUJjKHUHxxva5Dt p3n5okudj9vC5DPTh57VkSRJXSCkqZCubhzMAfIUDSE9OyLDAqgMkKdD5AbqsBQfHn5tDP +z36C9hY9I8PxjyJ2lOp09NQNZP/J3po6GBb5JxYlh53zKXj6gYd9Nv3M1K4Mw== 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] RPZ: update code to include WEBGUI and additional languages From: Michael Tremer In-Reply-To: <502fa002-d6da-45d6-9b3e-d4130e59f50a@ipfire.org> Date: Mon, 24 Mar 2025 14:25:40 +0000 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: <64617942-44E2-4E7B-A8AB-D5C22F94F68B@ipfire.org> References: <20250206163522.2363178-1-jon.murphy@ipfire.org> <8b594873-86ca-46b9-bb4b-94fd6b0239b1@ipfire.org> <9A0DBDA4-75B0-40D2-AE06-78D9BA5EE7D3@ipfire.org> <89101199-33D1-40AC-8CCE-DD97583129F2@ipfire.org> <8703C3D8-C30C-4A56-9F30-7B90BB1E3027@ipfire.org> <502fa002-d6da-45d6-9b3e-d4130e59f50a@ipfire.org> To: Bernhard Bitsch Hello, > On 24 Mar 2025, at 13:33, Bernhard Bitsch wrote: >=20 >=20 >=20 > Am 24.03.2025 um 11:17 schrieb Michael Tremer: >> Hello Jon, >>> On 24 Mar 2025, at 00:00, Jon Murphy wrote: >>>=20 >>> Michael, >>>=20 >>> FYI - I was wrong Unbound RPZ is _not_ watching the serial number, = it is watching the "refresh", the number after the serial number. >> Refresh just tells the client how often to check for an update. >> If that is actually being set by the list publisher, then we have = another problem here, because they could put some insanely low value = there and we would then DDoS their infrastructure. I think we should = keep it like we have it in other places that we control how often we = want to check or pull for updates. >>=20 >=20 > You are right. But an extra update process wastes additional processor = time. The update mechanism of unbound does the check for update ( = however it is realized ) nevertheless. Yes, doing more things needs resources. But we are not seriously = considering whether an IPFire system has enough resources to perform the = download of a text file, or are we? >>> I understand that you don=E2=80=99t speak C, but you got the = information from somewhere. Documentation maybe? Since that is out of = date very often I like to consult the code. >>> =46rom testing. Downloading rpz files using rpz unbound, and = watching what happens. If the rpz file is setup for "once per day" = refresh, then it only downloads one time. >>>=20 >>>=20 >>>=20 >>> However that won=E2=80=99t solve our problem . . . and having no = cache. >>> In `/etc/unbound/tuning.conf` there is `rrset-cache-size: 128m`. Are = you referring to a different cache. >> Naturally unbound is loading the zone into its memory which we = generally call cache. >> When I say cache I am thinking about persistent data storage across = multiple restarts of Unbound. If I am downloading 100 MiB of RPZ lists = (which is presumably still on the lower end) and I reboot my firewall, I = do not want to download the same data again. We can only ever download a = list *once* unless we are 100% certain that it has changed. Then we can = download it once again. >=20 > The RPZ lists are stored in files in persistent storage. Unbound = creates the internal cache from these. And where are these stored? >>> Maybe we need to implement both? >>>=20 >>> Yes. There are very few AXFR list (I think only four were found). = And many more HTTPS rpz files. >>>=20 >>>=20 >>>=20 >>> Jon >>>=20 >>>=20 >>> ------ Original Message ------ >>> =46rom "Michael Tremer" >>> To "Jon Murphy" >>> Cc "IPFire: Development-List" >>> Date 3/20/2025 11:26:43=E2=80=AFAM >>> Subject Re: [PATCH] RPZ: update code to include WEBGUI and = additional languages >>>=20 >>>> Hello Jon, >>>> Please don=E2=80=99t forget to Cc the list... >>>> =20 >>>>>=20 >>>>> On 19 Mar 2025, at 18:27, Jon Murphy = wrote: >>>>> Michael, >>>>> =20 >>>>>>=20 >>>>>> Where in the code is this implemented? I cannot find anything = like this: >>>>>=20 >>>>> Keep in mind I am not a "C" person. Maybe in this section?: >>>>> = https://git.ipfire.org/?p=3Dthirdparty/unbound.git;a=3Dblob;f=3Dservices/a= uthzone.c;hb=3D30b9cb5f813003d0a2b1c2e678652396615b1b7d#l5875 >>>>=20 >>>> This where the AXFR response is being handled when doing a DNS = zone transfer. This code is not being called when performing a HTTP = download. >>>> I understand that you don=E2=80=99t speak C, but you got the = information from somewhere. Documentation maybe? Since that is out of = date very often I like to consult the code. >>>> =20 >>>>>=20 >>>>> =E2=80=94 >>>>> When I was just learning about RPZ I created a separate RPZ file = for testing. When I changed the SOA line with a new serial number, the = RPZ file download would happen in about 5 minutes. >>>>> https://people.ipfire.org/~jon/sblack-adhoc.rpz >>>>=20 >>>> It might well be that the file is not being reloaded if the = download matches the content that unbound already has. That would of = course save some resources. >>>> However that won=E2=80=99t solve our problem with redundant = downloads and having no cache. >>>> =20 >>>>>=20 >>>>> That is how I found out the SOA line is watched for a serial = number change. >>>>> I=E2=80=99ll reconfirm my findings. >>>>> =20 >>>>>>=20 >>>>>>>> The second reason is that we have a lot of firewalls out there. = Not all of them will enable this feature and all of the lists, but even = if it is a good chunk, we will generate terabytes of traffic which put = load on the infrastructure and will cost money. It simply is not what we = want to do, regardless of self-hosting those lists and pulling them from = somewhere else. >>>>>=20 >>>>> So I understand, are you thinking of hosting RPZ AXFR (DNS zone = transfer) on IPFire infrastructure? >>>>=20 >>>> No, I don=E2=80=99t think that we can generally do this. The = biggest problem is licensing as we cannot take anyones content and host = it ourselves. We would re-distribute those lists and that will only work = with permission of the publishers. I assume that would be too much work = to actually get some useful content out there. We might limit ourselves = to only those lists that are under a very permissive license. Nobody = wants that. >>>> =46rom a technical point of view, DNS over TCP might not be very = nice in terms of forging the transfer and so we would need TLS as = well=E2=80=A6 It should work, but even if we would be able to encourage = other people to publish their lists I doubt they would implement DNS = over TLS for authoritative DNS. That standard is in very early stages as = well. >>>> As far as I can see, those vendors who offer a list as a = commercial product are using DNS to distribute it (e.g. Spamhaus). Those = people who have made this all a hobby are throwing the lists onto GitHub = and let them handle the traffic. >>>> Maybe we need to implement both? >>>> -Michael >>>> =20 >>>>>=20 >>>>> Jon >>>>> On 3/19/25 5:35 AM, Michael Tremer wrote: >>>>>>=20 >>>>>>=20 >>>>>> Hello Jon, >>>>>> Where in the code is this implemented? I cannot find anything = like this: >>>>>> Unbound loads the entire file into memory and then starts = parsing it. The only special treatment there is is to check whether the = first line is a valid zone entry. It does not even have to be a SOA = record. >>>>>> = https://git.ipfire.org/?p=3Dthirdparty/unbound.git;a=3Dblob;f=3Dservices/a= uthzone.c;hb=3D30b9cb5f813003d0a2b1c2e678652396615b1b7d#l1188 >>>>>> I am also concerned that Unbound will not be able to support an = upstream proxy for any downloads. The caching situation is also unclear = for me, so I believe that we will be looking at writing a custom = downloader that implements all these things. >>>>>> -Michael >>>>>> =20 >>>>>>>=20 >>>>>>> On 19 Mar 2025, at 02:58, Jon Murphy = wrote: >>>>>>> Michael, >>>>>>> =20 >>>>>>>>=20 >>>>>>>> The emphasis is on the repeated downloads of the same list. = That is >>>>>>>=20 >>>>>>> =E2=80=8B> what cannot happen. >>>>>>> The Unbound RPZ code, as installed within IPFire, watches for a = change >>>>>>> =E2=80=8Bin the SOA line of each RPZ file. This is an example of = the first few >>>>>>> =E2=80=8Blines for every RPZ file. >>>>>>> $TTL 300 >>>>>>> @ SOA localhost. root.localhost. 1742298960 43200 3600 86400 300 >>>>>>> NS localhost. >>>>>>> ; >>>>>>> ; Title: HaGeZi's Pop-Up Ads DNS Blocklist >>>>>>> ; Description: Blocks annoying and malicious pop-up ads. >>>>>>> If the SOA serial number changes (e.g. the 1742298960), then = Unbound RPZ >>>>>>> =E2=80=8Bcode does its thing and downloads. Otherwise there is = no download. >>>>>>> =20 >>>>>>>>=20 >>>>>>>> So there has to be a way to ensure that we won=E2=80=99t = download a list again >>>>>>>=20 >>>>>>> =E2=80=8B> unless it has actually changed. >>>>>>> This should do what you want but I may be missing your point. >>>>>>> =20 >>>>>>>>=20 >>>>>>>> DNS has a builtin functionality called AXFR. It simply does the = job >>>>>>>=20 >>>>>>> =E2=80=8B> for you. I was just wondering whether that was not = being used. >>>>>>> I need to read about AXFR/IXFR and learn a little more. >>>>>>> Jon >>>>>>> On 3/17/25 5:35 AM, Michael Tremer wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Good Morning Jon, >>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>> On 16 Mar 2025, at 17:00, Jon Murphy = wrote: >>>>>>>>> Michael, >>>>>>>>> I was reading through you response again an I want to = understand this post: >>>>>>>>> =20 >>>>>>>>>>=20 >>>>>>>>>> I have also stated that we cannot download any lists over = HTTPS again and again and again. The implementation that we have here = seems to exactly do that and therefore I think that my feedback has been = dismissed entirely. >>>>>>>>>=20 >>>>>>>>> So if RPZ doesn't use HTTPS, what is it using? I am missing a = key point here. >>>>>>>>=20 >>>>>>>> The emphasis is on the repeated downloads of the same list. = That is what cannot happen. >>>>>>>> Although it might not affect a lot of people in our general = user-base, there are some that have a metered connection and will pay = for data by volume. Some of the lists I looked at are just under 20 MiB. = Therefore we need to keep any traffic down to a minimum. The second = reason is that we have a lot of firewalls out there. Not all of them = will enable this feature and all of the lists, but even if it is a good = chunk, we will generate terabytes of traffic which put load on the = infrastructure and will cost money. It simply is not what we want to do, = regardless of self-hosting those lists and pulling them from somewhere = else. >>>>>>>> So there has to be a way to ensure that we won=E2=80=99t = download a list again unless it has actually changed. >>>>>>>> DNS has a builtin functionality called AXFR. It simply does = the job for you. I was just wondering whether that was not being used. >>>>>>>> HTTPS is an option because that is simply what we use = elsewhere, but extra functionality will have to be built for it. >>>>>>>> -Michael >>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>> Jon >>>>>>>>> On 2/13/25 3:34 PM, jon wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Michael, >>>>>>>>>> I=E2=80=99ve read through your comments a few times and I = ended up with many more questions. >>>>>>>>>> =20 >>>>>>>>>>>=20 >>>>>>>>>>> What I rather mean is that it has never been added as a = topic on the agenda and it has not been pitched by yourself. >>>>>>>>>>=20 >>>>>>>>>> To me the efforts to get new code accepted seem to have = changed and it seemed easier in the past. In the past I made the Core = Team aware via the Dev Mailing List and wrote a simple two or three = paragraphs of "What is it? / What is the value? / Here is the code" >>>>>>>>>> So in an effort to move forward: How exactly is something = presented to the Core Team? >>>>>>>>>> Is there an example of a recent effort that was presented = that I can see as a sample? (This type of info can also be added to the = Wiki) >>>>>>>>>> I understand you want it this way, but I don=E2=80=99t know = what exactly is needed. Please be specific. >>>>>>>>>> Jon >>>>>>>>>> PS - I am not ignoring your other comments, I am just trying = to move forward and keep things simple. >>>>>>>>>> =20 >>>>>>>>>>>=20 >>>>>>>>>>> On Feb 8, 2025, at 1:27=E2=80=AFPM, Michael Tremer = wrote: >>>>>>>>>>> Hello Jon, >>>>>>>>>>> Thanks for your reply. And good that you are copying = everyone into this conversation. >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 8 Feb 2025, at 18:41, jon wrote: >>>>>>>>>>>> Michael, >>>>>>>>>>>> =20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I think I have covered this all at lengths before that = this project has been started as a separate effort >>>>>>>>>>>>=20 >>>>>>>>>>>> Yes, this has been a separate effort (a very public = separate effort). Yes, as you pointed this out early on with the = "proof-of-concept" and then my request for people to help test RPZ. = Nothing was hidden. >>>>>>>>>>>> This was done because you (and maybe others) did not have = the time and I wanted to help and because I needed assistance with RPZ. = I tried my best to do this without bothering you. >>>>>>>>>>>=20 >>>>>>>>>>> I don=E2=80=99t that it is accurate that nobody wanted to = help on this. The list was always open - although not every email has = been replied to swiftly it is also your responsibility to raise a = question again if it was missed. People here have open ears. >>>>>>>>>>> It was also stated on this very list on in our = documentation that working on something without involving the core team = is a risky undertaking. Of course IPFire is free software and so = everyone is free to fork if they wish to do so. >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> and as far as I am aware none of the other team members = has been involved. This has not been discussed either on this list, on = our calls. >>>>>>>>>>>>=20 >>>>>>>>>>>> You were aware many steps along the way. See your email on = July 28, 2024, August 15, 2024, September 30, 2024, December 23, 2024, = and January 16. My attempts to get the team involved were met with = "things are busy" and sometimes silence. (Yes, I get it, people are = busy.) >>>>>>>>>>>> You and Adolf, Leo, Erik and Bernhard have been aware = since the beginning. You mention you were aware of the = "proof-of-concept". If you include those beginning posts, since Sep = 2023. >>>>>>>>>>>=20 >>>>>>>>>>> Yes, I am aware of a proof-of-concept that I have been = running myself for a long time. I am also aware of the efforts that you = have been taking. >>>>>>>>>>> Yet I don=E2=80=99t think there has ever been any joint = effort, or am I seeing that wrong? >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> This has not been discussed . . . on our calls. >>>>>>>>>>>>=20 >>>>>>>>>>>> On the July 28th you stated: >>>>>>>>>>>> "We have talked about RPZ many times on the monthly call = since the URL filter feature is falling more and more out of fashion. I = think there is also many posts about this on the forum." >>>>>>>>>>>> Please don=E2=80=99t insult me again by stating "you know = what I mean". >>>>>>>>>>>> And it has been discussed but not documented in the = Monthly Meeting notes. >>>>>>>>>>>=20 >>>>>>>>>>> I am not at all insulting you. I don=E2=80=99t want to take = this down to a personal level at all. This is a public mailing list and = people who read this don=E2=80=99t need to listen to an argument we are = having. They are here for the tech inside IPFire. >>>>>>>>>>> When I wrote that it has not been discussed that does not = mean that we have not been touching on the topic. We have been talking = about lots of things on the calls, the weather, politics, how our pets = are. None of that makes it to the logs. What I rather mean is that it = has never been added as a topic on the agenda and it has not been = pitched by yourself. >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> Instead there has been a separate conversation on the = forum with the occasional dip here to the list. But that was not a = regular two-way conversation. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regular conversation on the Dev Mailing list is many times = met with silence. I get it, people are busy. >>>>>>>>>>>> And regular two-way conversation doesn=E2=80=99t happen on = the list. At least not with me. I=E2=80=99d be happy to point out the = posts that were met with silence. >>>>>>>>>>>> Again, I get it, people are busy. >>>>>>>>>>>=20 >>>>>>>>>>> And you think my emails are not being met with silence? This = has nothing to do with this specific topic. This has something to do = with how occupied people are and how engaged they are on certain topics. = Not everyone is involved in all the things and simply will ignore emails = simply based on their subject line. >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But the "dip here to the list" were my attempts to get a = conversation started. As I said, many time met with silence. >>>>>>>>>>>> The only place I was not met with silence was on the = Community. You have a great group of people in the Community. It is a = shame you don=E2=80=99t want to have others help. It would reduce your = workload. >>>>>>>>>>>=20 >>>>>>>>>>> You should stop making statements that are not true. Who = doesn=E2=80=99t want anyone to help? >>>>>>>>>>> Not having this conversation on a Saturday evening would = reduce my workload. At least it would free up time for something else. = Helping with the things that are already on the go would reduce the = workload of the entire team. Starting one thing at a time and finishing = it is a lot better to manage than starting a hundred things and not even = finish one. I can tell you that I already have a hundred things on the = go. >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> Therefore, what am I supposed to do with this email? >>>>>>>>>>>>=20 >>>>>>>>>>>> To me it is beyond obvious=E2=80=A6 >>>>>>>>>>>> If it isn=E2=80=99t what you want, then guide me with how = to do this the correct way. And be specific. I am trying to help. I am = trying to make things better. I am trying to do things the right way. >>>>>>>>>>>=20 >>>>>>>>>>> To me it isn=E2=80=99t. This is yet another project that has = been dumped to the list like so many before and later on everyone has = left to have the team deal with the rest. >>>>>>>>>>> It is a huge patch set. You explained what the vision is, = but that is about it. There is no chance this will continue if this = disagreement isn=E2=80=99t solved first. I didn=E2=80=99t even look at = the code. >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> I don=E2=80=99t want to merge code that I don=E2=80=99t = agree with. >>>>>>>>>>>>=20 >>>>>>>>>>>> I asked multiple times if you "agreed with the concept" and = again, met with silence. Yes I get it, people are busy. >>>>>>>>>>>=20 >>>>>>>>>>> Having support for RPZ? Yes, it was definitely on the = roadmap. That I agree with. >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> So many fundamental things that I have been raising have = either not been discussed or outright dismissed. >>>>>>>>>>>>=20 >>>>>>>>>>>> You mentioned this a in the past, but for some reason you = do not disclose what I dismissed. Why do you continue to make this = harder, wouldn=E2=80=99t it not be easier to tell me what I have = dismissed? >>>>>>>>>>>> I have sent multiple emails trying to answer your concerns = and comments. On July 28, Aug 14, Aug 22, Aug 23, Sep 30, etc. >>>>>>>>>>>> I=E2=80=99ve gone through all of the questions you asked = and I cannot find a "dismissed" item. >>>>>>>>>>>=20 >>>>>>>>>>> Maybe I need to be *more clear*. I feel humoured by this. >>>>>>>>>>> It is late on a Saturday and I want my dinner soon, but = certainly I have stated that this should never be an add-on considering = it is supposed to replace URL Filter. We should never allow people to = add their own sources. I have also stated that we cannot download any = lists over HTTPS again and again and again. The implementation that we = have here seems to exactly do that and therefore I think that my = feedback has been dismissed entirely. >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> I don=E2=80=99t want to merge code that has no future = inside IPFire as there is no constructive conversation with the = maintainers of it. >>>>>>>>>>>>=20 >>>>>>>>>>>> The maintainers of Unbound and/or RPZ? >>>>>>>>>>>> The maintainers of Hagezi list, the threatfox list, the = urlhaus list, etc.? >>>>>>>>>>>> What else? The maintainers or the RPZ scripts? That is me. = Let=E2=80=99s talk! >>>>>>>>>>>=20 >>>>>>>>>>> You. I don=E2=80=99t care much about the providers of the = lists. >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> See, this is where it gets confusing. There are hundreds of = open source packages as part of IPFire. Pick the last five years of = items added to the IPFire build. You're telling me you have = "constructive conversation with the maintainers" of all of the added = packages? >>>>>>>>>>>=20 >>>>>>>>>>> They publish their software and they don=E2=80=99t care = whether I am pulling it or not. They publish it with the commitment to = maintain it - sometimes for better and sometimes for worse. >>>>>>>>>>> You care about me pulling your code and I don=E2=80=99t = know whether you would commit to maintain this. >>>>>>>>>>> These two are very different cases. >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Pick the IP Blocklists list (i.e., 3CORESEC, ABUSECH, = DSHIELD, SPAMHAUS, etc.) or the Suricata lists (i.e.,Emergingthreats.net = ,Abuse.ch , etc.). So = you=E2=80=99ve have "constructive conversation with the maintainers"? >>>>>>>>>>>=20 >>>>>>>>>>> Yes, occasionally I have phone calls with a few of these = providers. >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> Having been trying for a long time to make you aware of = this, nothing of this should come as a surprise. >>>>>>>>>>>>=20 >>>>>>>>>>>> Ha! Yes a surprise. In the beginning you seemed interested = as IPFire needed a replacement for URL Filter. You asked good questions = about the lists picked, asked for the value to the users, etc. And I = answered the best I could. >>>>>>>>>>>> You even asked: =E2=80=9CWhy is this realised as an add-on = and not part of the core system?=E2=80=9D from your Jul 28, 2024 email. >>>>>>>>>>>=20 >>>>>>>>>>> Ah, so, why is the patch creating an add-on? Not that I am = saying that what I say is law, but it has not been challenged either. If = my input is being ignored, why should I put this to the top of my list = of priorities? I am not disappointed about this, just trying to be very = good with my time. >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> And on January 16, 2025 I wrote a message looking for help. = And you were kind to respond quickly. So in three weeks time, since the = kind response, something has changed. You went from supportive to = "this". >>>>>>>>>>>> So yes, I am surprised. >>>>>>>>>>>=20 >>>>>>>>>>> Well, maybe I should not have replied to that email. It was = clear that you were on some path that was not right, but you were not = interested before in finding the right path from the beginning. >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> Please consider if that can be changed and if there is a = path forward with this. >>>>>>>>>>>>=20 >>>>>>>>>>>> Be more specific, what has to change? What exactly did I = dismiss? >>>>>>>>>>>=20 >>>>>>>>>>> Dismissal is just my assumption. I don=E2=80=99t know what = you actually did with my feedback. I can only see the end product that = does not seem contain much of it. Repeatedly I have been pointing out = that we should think before we build. I am sure a lot of hours have now = gone into some code that simply does not satisfy me. And I am not not = talking about the code itself, what it does is what I don=E2=80=99t = think is right for us. >>>>>>>>>>> The process is very clear for me that we should first of = all think whether we want a certain feature now. Then there should be a = clear roadmap for everyone to follow; tasks can be split-up as we go and = hopefully then have something that is maintainable, interesting for our = users and even would do us proud. This is how this should work. >>>>>>>>>>> So, what has to change? I don=E2=80=99t think with shouting = at each other, throwing patches around and making me generally unhappy = is a good start. >>>>>>>>>>> -Michael >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Jon >>>>>>>>>>>> =20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Feb 6, 2025, at 2:13=E2=80=AFPM, Michael Tremer = wrote: >>>>>>>>>>>>> Hello Jon, >>>>>>>>>>>>> Well, here we are again with another patch regarding this = feature. >>>>>>>>>>>>> I cannot quite see from your email what the question is, = but if this is a request to have this merged into IPFire, I am once = again sorry to disappoint you. >>>>>>>>>>>>> I think I have covered this all at lengths before that = this project has been started as a separate effort and as far as I am = aware none of the other team members has been involved. This has not = been discussed either on this list, on our calls. Instead there has been = a separate conversation on the forum with the occasional dip here to the = list. But that was not a regular two-way conversation. Therefore, what = am I supposed to do with this email? >>>>>>>>>>>>> I don=E2=80=99t want to merge code that I don=E2=80=99t = agree with. So many fundamental things that I have been raising have = either not been discussed or outright dismissed. >>>>>>>>>>>>> I don=E2=80=99t want to merge code that has no future = inside IPFire as there is no constructive conversation with the = maintainers of it. >>>>>>>>>>>>> Having been trying for a long time to make you aware of = this, nothing of this should come as a surprise. >>>>>>>>>>>>> Please consider if that can be changed and if there is a = path forward with this. >>>>>>>>>>>>> All the best, >>>>>>>>>>>>> -Michael >>>>>>>>>>>>> =20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 6 Feb 2025, at 16:35, Jon Murphy = wrote: >>>>>>>>>>>>>> What is it? >>>>>>>>>>>>>> Response Policy Zone (RPZ) is a mechanism to define local = policies in a >>>>>>>>>>>>>> standardized way and load those policies from external = sources. >>>>>>>>>>>>>> Bottom line: RPZ allows admins to easily block access to = websites via DNS lookup. >>>>>>>>>>>>>> RPZ can block websites via categories. Examples include: = fake websites, annoying >>>>>>>>>>>>>> pop-up ads, newly registered domains, DoH bypass sites, = bad "host" services, >>>>>>>>>>>>>> maliscious top level domains (e.g., *.zip, *.mov), = piracy, gambling, pornography, >>>>>>>>>>>>>> and more. RPZ lists come from various RPZ providers and = their available >>>>>>>>>>>>>> catagories. >>>>>>>>>>>>>> This RPZ add-on enables the RPZ functionality by adding = a couple lines in a >>>>>>>>>>>>>> configuration file. This add-on simply adds configuration = files and adds >>>>>>>>>>>>>> scripts (config, metrics and sleep) to make RPZ easier = for the admin to use. >>>>>>>>>>>>>> The RPZ scripts include additional languages: German, = Spanish, French, Turkish, >>>>>>>>>>>>>> and Italian. >>>>>>>>>>>>>> RPZ itself was release in 2010 and has been part of the = IPFire build since ~2015. >>>>>>>>>>>>>> Why is it needed? What is its value? >>>>>>>>>>>>>> - The RPZ concept places this filtering into IPFire, our = internet access >>>>>>>>>>>>>> gateway, which is (should be) solely used as DNS source = of the internal network. >>>>>>>>>>>>>> - As most sites use HTTPS it makes it difficult to = filter traffic with URL >>>>>>>>>>>>>> Filter without also properly configuring conventional = (non-transparent) >>>>>>>>>>>>>> mode on the proxy. RPZ is a nice replacement for the URL = Filter. >>>>>>>>>>>>>> - No need to install and maintain an additional device = like PiHole or AdBlock >>>>>>>>>>>>>> browser extensions on multiple user devices. >>>>>>>>>>>>>> - This is an additional layer of protection for users. = Less worry someone will >>>>>>>>>>>>>> click on something that gets them into trouble. And, = saying this with emphasis, >>>>>>>>>>>>>> the ability to do it in one place! >>>>>>>>>>>>>> - Blocked sites save on unneeded traffic and can lessen = the threat of malware >>>>>>>>>>>>>> in advertisements >>>>>>>>>>>>>> - Logging allows the admin to see the site blocked and = take actions >>>>>>>>>>>>>> - RPZ will be used at the home, home-office (work from = home), schools, >>>>>>>>>>>>>> ministerial, and at the office. Device counts are small = (2-6) to medium (~80) >>>>>>>>>>>>>> to mediam-large (200+). >>>>>>>>>>>>>> - RPZ can block ads, popups, phishing, scammers, = spyware, malware, annoying >>>>>>>>>>>>>> popups, NSFW links, DOH servers, and the usual internet = trash. >>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>> Change Log for RPZ add-on >>>>>>>>>>>>>> rpz-1.0.0-18 on 2025-02-05 >>>>>>>>>>>>>> - Build for approval & release as IPFire add-on >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> rpz-beta-0.1.18-18.ipfire on 2025-02-01 >>>>>>>>>>>>>> rpz.cgi: >>>>>>>>>>>>>> - new feature: added a mod key to force a unbound restart >>>>>>>>>>>>>> rpz-config and rpz-make: >>>>>>>>>>>>>> - new feature: added action for unbound restart = `rpz-config unbound-restart` >>>>>>>>>>>>>> rpz-metrics: >>>>>>>>>>>>>> - simple reformatting >>>>>>>>>>>>>> - rename far right column from "last update" to "last = download" >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> rpz-beta-0.1.17-17.ipfire on 2024-12-09 >>>>>>>>>>>>>> rpz-make >>>>>>>>>>>>>> - bug fix: corrected validation regex for wildcards like: = `*.domain.com` >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> rpz-beta-0.1.16-16.ipfire on 2024-11-18 >>>>>>>>>>>>>> rpz-make >>>>>>>>>>>>>> - new feature: updated validation regex >>>>>>>>>>>>>> - bug fix: moved validation to beginning of process. Now = we validate before >>>>>>>>>>>>>> creating config files. >>>>>>>>>>>>>> rpz.cgi: >>>>>>>>>>>>>> - new feature: use CSS color variables of the main ipfire = theme >>>>>>>>>>>>>> - bug fix: empty zonefile remarks were stored as = =E2=80=9Cundef=E2=80=9D and caused a warning >>>>>>>>>>>>>> - bug fix: HTML textarea removes the first empty line in = a custom list >>>>>>>>>>>>>> - thank you Leo! >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> rpz-beta-0.1.15-15.ipfire on 2024-11-04 >>>>>>>>>>>>>> rpz.cgi: >>>>>>>>>>>>>> - new feature: added new language file for Turkish (thank = you Peppe) >>>>>>>>>>>>>> rpz-make >>>>>>>>>>>>>> - bug fix: corrected empty allow/block list issue. An = empty allow/block list >>>>>>>>>>>>>> will now remove contents of allow/block.rpz files and = remove unneeded >>>>>>>>>>>>>> allow/block.conf file. (thank you iptom) >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> rpz-beta-0.1.14-14.ipfire on 2024-10-29 >>>>>>>>>>>>>> rpz-config: >>>>>>>>>>>>>> - bug fix: correct missing rpz extension. `rpz-config = list` displayed URL >>>>>>>>>>>>>> incorrectly (thank you Bernhard) >>>>>>>>>>>>>> rpz.cgi: >>>>>>>>>>>>>> - bug fix: remove extra `"` in language files (thank you = Bernhard) >>>>>>>>>>>>>> - new feature: slightly dim "apply" button when not = enabled >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> rpz-beta-0.1.13-13.ipfire on 2024-10-27 >>>>>>>>>>>>>> - skipped >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> rpz-beta-0.1.12-12.ipfire on 2024-10-21 >>>>>>>>>>>>>> rpz.cgi: >>>>>>>>>>>>>> - new feature: added new language file for French (thank = you gw-ipfire) >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> rpz-beta-0.1.11-11.ipfire on 2024-10-18 >>>>>>>>>>>>>> rpz.cgi: >>>>>>>>>>>>>> - new feature: added new language file for Italian (thank = you umberto) >>>>>>>>>>>>>> - new feature: added new language file for Spanish (thank = you Roberto) >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> rpz-beta-0.1.10-10.ipfire on 2024-10-15 >>>>>>>>>>>>>> rpz-make: >>>>>>>>>>>>>> - bug fix: corrected validation error for a custom list = entry (thank you siosios) >>>>>>>>>>>>>> - e.g., `*.cloudflare-dns.com` >>>>>>>>>>>>>> install.sh: >>>>>>>>>>>>>> - bug fix: add chown to correct user created files >>>>>>>>>>>>>> update.sh: >>>>>>>>>>>>>> - bug fix: add chown to correct user created files (thank = you siosios) >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> rpz-beta-0.1.9-9.ipfire on 2024-10-08 >>>>>>>>>>>>>> rpz.cgi: >>>>>>>>>>>>>> - new feature: added new language file for German (thank = you Leo) >>>>>>>>>>>>>> - bug fix: add missing "rpz exitcode 110" >>>>>>>>>>>>>> - bug fix: corrected missing RPZ menu item at menu > = IPFire >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> rpz-beta-0.1.8-8.ipfire on 2024-10-04 >>>>>>>>>>>>>> - skipped >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> rpz-beta-0.1.7-7.ipfire on 2024-10-03 >>>>>>>>>>>>>> All: >>>>>>>>>>>>>> - new feature: includes beta version numbers for pakfire = package, >>>>>>>>>>>>>> instead of only `rpz-1.0.0-1.ipfire`, for each release. >>>>>>>>>>>>>> rpz.cgi: >>>>>>>>>>>>>> - new feature: added new WebGUI at `rpz.cgi` >>>>>>>>>>>>>> - a BIG thank you to Leo Hofmann for all of his work = creating the webgui!! >>>>>>>>>>>>>> - bug fix: corrected missing RPZ menu item at menu > = IPFire >>>>>>>>>>>>>> rpz-make: >>>>>>>>>>>>>> - new feature: validate entries in allowlist and = blocklist >>>>>>>>>>>>>> - new feature: add "no-reload" option for WebGUI >>>>>>>>>>>>>> rpz-metrics: >>>>>>>>>>>>>> - new feature: info can be sorted by name, by hit count, = by line count, by >>>>>>>>>>>>>> "enabled" list or all lists >>>>>>>>>>>>>> backups: >>>>>>>>>>>>>> - bug fix: include all files in `/var/ipfire/dns/rpz` = directory in backup >>>>>>>>>>>>>> update.sh: >>>>>>>>>>>>>> - bug fix: corrected ownership for `/var/ipfire/dns/rpz` = directory during an >>>>>>>>>>>>>> update >>>>>>>>>>>>>> Build: >>>>>>>>>>>>>> - bug fix: `block.rpz.conf` and `block.rpz` from build. = Files to be created >>>>>>>>>>>>>> by `rpz-make` >>>>>>>>>>>>>> WebGUI and German language file >>>>>>>>>>>>>> Contribution-by: Leo-Andres Hofmann = >>>>>>>>>>>>>> Spanish language file >>>>>>>>>>>>>> Contribution-by: Roberto Pe=C3=B1a >>>>>>>>>>>>>> Italian language file >>>>>>>>>>>>>> Contribution-by: Umberto Parma >>>>>>>>>>>>>> French language file >>>>>>>>>>>>>> Contribution-by: gw-ipfire >>>>>>>>>>>>>> Turkish language file >>>>>>>>>>>>>> Contribution-by: Peppe Tech >>>>>>>>>>>>>> Contribution-by: Bernhard Bitsch >>>>>>>>>>>>>> Contribution-by: Erik Kapfer >>>>>>>>>>>>>> Signed-off-by: Jon Murphy >>>>>>>>>>>>> --- >>>>>>>>>>>>>> config/backup/includes/rpz | 4 + >>>>>>>>>>>>>> config/cfgroot/manualpages | 1 + >>>>>>>>>>>>>> config/menu/EX-rpz.menu | 6 + >>>>>>>>>>>>>> config/rootfiles/common/configroot | 1 + >>>>>>>>>>>>>> config/rootfiles/common/web-user-interface | 1 + >>>>>>>>>>>>>> config/rootfiles/packages/rpz | 20 + >>>>>>>>>>>>>> config/rpz/00-rpz.conf | 10 + >>>>>>>>>>>>>> config/rpz/rpz-config | 130 +++ >>>>>>>>>>>>>> config/rpz/rpz-functions | 85 ++ >>>>>>>>>>>>>> config/rpz/rpz-make | 203 +++++ >>>>>>>>>>>>>> config/rpz/rpz-metrics | 170 ++++ >>>>>>>>>>>>>> config/rpz/rpz-sleep | 58 ++ >>>>>>>>>>>>>> config/rpz/rpz.de.pl | 30 + >>>>>>>>>>>>>> config/rpz/rpz.en.pl | 30 + >>>>>>>>>>>>>> config/rpz/rpz.es.pl | 30 + >>>>>>>>>>>>>> config/rpz/rpz.fr.pl | 30 + >>>>>>>>>>>>>> config/rpz/rpz.it.pl | 30 + >>>>>>>>>>>>>> config/rpz/rpz.tr.pl | 30 + >>>>>>>>>>>>>> html/cgi-bin/rpz.cgi | 923 +++++++++++++++++++++ >>>>>>>>>>>>>> lfs/rpz | 96 +++ >>>>>>>>>>>>>> make.sh | 3 +- >>>>>>>>>>>>>> src/paks/rpz/install.sh | 36 + >>>>>>>>>>>>>> src/paks/rpz/uninstall.sh | 38 + >>>>>>>>>>>>>> src/paks/rpz/update.sh | 52 ++ >>>>>>>>>>>>>> 24 files changed, 2016 insertions(+), 1 deletion(-) >>>>>>>>>>>>>> create mode 100644 config/backup/includes/rpz >>>>>>>>>>>>>> create mode 100644 config/menu/EX-rpz.menu >>>>>>>>>>>>>> create mode 100644 config/rootfiles/packages/rpz >>>>>>>>>>>>>> create mode 100644 config/rpz/00-rpz.conf >>>>>>>>>>>>>> create mode 100644 config/rpz/rpz-config >>>>>>>>>>>>>> create mode 100644 config/rpz/rpz-functions >>>>>>>>>>>>>> create mode 100644 config/rpz/rpz-make >>>>>>>>>>>>>> create mode 100755 config/rpz/rpz-metrics >>>>>>>>>>>>>> create mode 100755 config/rpz/rpz-sleep >>>>>>>>>>>>>> create mode 100644 config/rpz/rpz.de.pl >>>>>>>>>>>>>> create mode 100644 config/rpz/rpz.en.pl >>>>>>>>>>>>>> create mode 100644 config/rpz/rpz.es.pl >>>>>>>>>>>>>> create mode 100644 config/rpz/rpz.fr.pl >>>>>>>>>>>>>> create mode 100644 config/rpz/rpz.it.pl >>>>>>>>>>>>>> create mode 100644 config/rpz/rpz.tr.pl >>>>>>>>>>>>>> create mode 100644 html/cgi-bin/rpz.cgi >>>>>>>>>>>>>> create mode 100644 lfs/rpz >>>>>>>>>>>>>> create mode 100644 src/paks/rpz/install.sh >>>>>>>>>>>>>> create mode 100644 src/paks/rpz/uninstall.sh >>>>>>>>>>>>>> create mode 100644 src/paks/rpz/update.sh >>>>>>>>>>>>>> diff --git a/config/backup/includes/rpz = b/config/backup/includes/rpz >>>>>>>>>>>>>> new file mode 100644 >>>>>>>>>>>>>> index 000000000..36513e494 >>>>>>>>>>>>>> --- /dev/null >>>>>>>>>>>>>> +++ b/config/backup/includes/rpz >>>>>>>>>>>>>> @@ -0,0 +1,4 @@ >>>>>>>>>>>>>> +/var/ipfire/dns/rpz/* >>>>>>>>>>>>>> +/etc/unbound/zonefiles/allow.rpz >>>>>>>>>>>>>> +/etc/unbound/zonefiles/block.rpz >>>>>>>>>>>>>> +/etc/unbound/local.d/*rpz.conf >>>>>>>>>>>>>> diff --git a/config/cfgroot/manualpages = b/config/cfgroot/manualpages >>>>>>>>>>>>>> index 1f7e01efc..d3a48c633 100644 >>>>>>>>>>>>>> --- a/config/cfgroot/manualpages >>>>>>>>>>>>>> +++ b/config/cfgroot/manualpages >>>>>>>>>>>>>> @@ -70,6 +70,7 @@ = pakfire.cgi=3Dconfiguration/ipfire/pakfire >>>>>>>>>>>>>> wlanap.cgi=3Daddons/wireless >>>>>>>>>>>>>> tor.cgi=3Daddons/tor >>>>>>>>>>>>>> samba.cgi=3Daddons/samba >>>>>>>>>>>>>> +rpz.cgi=3Daddons/rpz >>>>>>>>>>>>>> # Logs menu >>>>>>>>>>>>>> logs.cgi/summary.dat=3Dconfiguration/logs/summary >>>>>>>>>>>>>> diff --git a/config/menu/EX-rpz.menu = b/config/menu/EX-rpz.menu >>>>>>>>>>>>>> new file mode 100644 >>>>>>>>>>>>>> index 000000000..2f4daf410 >>>>>>>>>>>>>> --- /dev/null >>>>>>>>>>>>>> +++ b/config/menu/EX-rpz.menu >>>>>>>>>>>>>> @@ -0,0 +1,6 @@ >>>>>>>>>>>>>> +$subipfire->{'20.rpz'} =3D { >>>>>>>>>>>>>> + 'caption' =3D> $Lang::tr{'rpz'}, >>>>>>>>>>>>>> + 'uri' =3D> '/cgi-bin/rpz.cgi', >>>>>>>>>>>>>> + 'title' =3D> "RPZ", >>>>>>>>>>>>>> + 'enabled' =3D> 1, >>>>>>>>>>>>>> +}; >>>>>>>>>>>>>> diff --git a/config/rootfiles/common/configroot = b/config/rootfiles/common/configroot >>>>>>>>>>>>>> index 9839eee45..b30d6aae4 100644 >>>>>>>>>>>>>> --- a/config/rootfiles/common/configroot >>>>>>>>>>>>>> +++ b/config/rootfiles/common/configroot >>>>>>>>>>>>>> @@ -120,6 +120,7 @@ var/ipfire/menu.d/70-log.menu >>>>>>>>>>>>>> #var/ipfire/menu.d/EX-apcupsd.menu >>>>>>>>>>>>>> #var/ipfire/menu.d/EX-guardian.menu >>>>>>>>>>>>>> #var/ipfire/menu.d/EX-mympd.menu >>>>>>>>>>>>>> +#var/ipfire/menu.d/EX-rpz.menu >>>>>>>>>>>>>> #var/ipfire/menu.d/EX-samba.menu >>>>>>>>>>>>>> #var/ipfire/menu.d/EX-tor.menu >>>>>>>>>>>>>> #var/ipfire/menu.d/EX-transmission.menu >>>>>>>>>>>>>> diff --git a/config/rootfiles/common/web-user-interface = b/config/rootfiles/common/web-user-interface >>>>>>>>>>>>>> index 816241dae..e00464076 100644 >>>>>>>>>>>>>> --- a/config/rootfiles/common/web-user-interface >>>>>>>>>>>>>> +++ b/config/rootfiles/common/web-user-interface >>>>>>>>>>>>>> @@ -69,6 +69,7 @@ srv/web/ipfire/cgi-bin/proxy.cgi >>>>>>>>>>>>>> srv/web/ipfire/cgi-bin/qos.cgi >>>>>>>>>>>>>> srv/web/ipfire/cgi-bin/remote.cgi >>>>>>>>>>>>>> srv/web/ipfire/cgi-bin/routing.cgi >>>>>>>>>>>>>> +#srv/web/ipfire/cgi-bin/rpz.cgi >>>>>>>>>>>>>> #srv/web/ipfire/cgi-bin/samba.cgi >>>>>>>>>>>>>> srv/web/ipfire/cgi-bin/services.cgi >>>>>>>>>>>>>> srv/web/ipfire/cgi-bin/shutdown.cgi >>>>>>>>>>>>>> diff --git a/config/rootfiles/packages/rpz = b/config/rootfiles/packages/rpz >>>>>>>>>>>>>> new file mode 100644 >>>>>>>>>>>>>> index 000000000..1c8663049 >>>>>>>>>>>>>> --- /dev/null >>>>>>>>>>>>>> +++ b/config/rootfiles/packages/rpz >>>>>>>>>>>>>> @@ -0,0 +1,20 @@ >>>>>>>>>>>>>> +etc/unbound/local.d/00-rpz.conf >>>>>>>>>>>>>> +etc/unbound/zonefiles >>>>>>>>>>>>>> +etc/unbound/zonefiles/allow.rpz >>>>>>>>>>>>>> +usr/sbin/rpz-config >>>>>>>>>>>>>> +usr/sbin/rpz-functions >>>>>>>>>>>>>> +usr/sbin/rpz-make >>>>>>>>>>>>>> +usr/sbin/rpz-metrics >>>>>>>>>>>>>> +usr/sbin/rpz-sleep >>>>>>>>>>>>>> +var/ipfire/addon-lang/rpz.de.pl >>>>>>>>>>>>>> +var/ipfire/addon-lang/rpz.en.pl >>>>>>>>>>>>>> +var/ipfire/addon-lang/rpz.es.pl >>>>>>>>>>>>>> +var/ipfire/addon-lang/rpz.fr.pl >>>>>>>>>>>>>> +var/ipfire/addon-lang/rpz.it.pl >>>>>>>>>>>>>> +var/ipfire/addon-lang/rpz.tr.pl >>>>>>>>>>>>>> +var/ipfire/backup/addons/includes/rpz >>>>>>>>>>>>>> +var/ipfire/dns/rpz >>>>>>>>>>>>>> +var/ipfire/dns/rpz/allowlist >>>>>>>>>>>>>> +var/ipfire/dns/rpz/blocklist >>>>>>>>>>>>>> +var/ipfire/menu.d/EX-rpz.menu >>>>>>>>>>>>>> +srv/web/ipfire/cgi-bin/rpz.cgi >>>>>>>>>>>>>> diff --git a/config/rpz/00-rpz.conf = b/config/rpz/00-rpz.conf >>>>>>>>>>>>>> new file mode 100644 >>>>>>>>>>>>>> index 000000000..f005a4f2e >>>>>>>>>>>>>> --- /dev/null >>>>>>>>>>>>>> +++ b/config/rpz/00-rpz.conf >>>>>>>>>>>>>> @@ -0,0 +1,10 @@ >>>>>>>>>>>>>> +server: >>>>>>>>>>>>>> + module-config: "respip validator iterator" >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +rpz: >>>>>>>>>>>>>> + name: allow.rpz >>>>>>>>>>>>>> + zonefile: /etc/unbound/zonefiles/allow.rpz >>>>>>>>>>>>>> + rpz-action-override: passthru >>>>>>>>>>>>>> + rpz-log: yes >>>>>>>>>>>>>> + rpz-log-name: allow >>>>>>>>>>>>>> + rpz-signal-nxdomain-ra: yes >>>>>>>>>>>>>> diff --git a/config/rpz/rpz-config = b/config/rpz/rpz-config >>>>>>>>>>>>>> new file mode 100644 >>>>>>>>>>>>>> index 000000000..c72d50f9b >>>>>>>>>>>>>> --- /dev/null >>>>>>>>>>>>>> +++ b/config/rpz/rpz-config >>>>>>>>>>>>>> @@ -0,0 +1,130 @@ >>>>>>>>>>>>>> +#!/bin/bash >>>>>>>>>>>>>> = +#########################################################################= ###### >>>>>>>>>>>>>> +# # >>>>>>>>>>>>>> +# IPFire.org - A linux based firewall # >>>>>>>>>>>>>> +# Copyright (C) 2024-2025 IPFire Team = # >>>>>>>>>>>>>> +# # >>>>>>>>>>>>>> +# This program is free software: you can redistribute it = and/or modify # >>>>>>>>>>>>>> +# it under the terms of the GNU General Public License = as published by # >>>>>>>>>>>>>> +# the Free Software Foundation, either version 3 of the = License, or # >>>>>>>>>>>>>> +# (at your option) any later version. # >>>>>>>>>>>>>> +# # >>>>>>>>>>>>>> +# This program is distributed in the hope that it will = be useful, # >>>>>>>>>>>>>> +# but WITHOUT ANY WARRANTY; without even the implied = warranty of # >>>>>>>>>>>>>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. = See the # >>>>>>>>>>>>>> +# GNU General Public License for more details. # >>>>>>>>>>>>>> +# # >>>>>>>>>>>>>> +# You should have received a copy of the GNU General = Public License # >>>>>>>>>>>>>> +# along with this program. If not, see = . # >>>>>>>>>>>>>> +# # >>>>>>>>>>>>>> = +#########################################################################= ###### >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +version=3D"2025-01-11 - v44" >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +############### Functions ############### >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +source /usr/sbin/rpz-functions >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +############### Main ############### >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +tagName=3D"unbound" >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +rpzAction=3D"${1}" # input RPZ action >>>>>>>>>>>>>> +rpzName=3D"${2}" # input RPZ name >>>>>>>>>>>>>> +rpzURL=3D"${3}" # input RPZ URL >>>>>>>>>>>>>> +rpzOption1=3D"${4}" # input RPZ option #1 >>>>>>>>>>>>>> +rpzOption2=3D"${5}" # input RPZ option #2 >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +rpzConfig=3D"/etc/unbound/local.d/${rpzName}.rpz.conf" # = output zone conf file >>>>>>>>>>>>>> +rpzFile=3D"/etc/unbound/zonefiles/${rpzName}.rpz" # = output for RPZ file >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +rpzLog=3D"yes" # log default is yes >>>>>>>>>>>>>> +ucReload=3D"yes" # reload default is yes >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +while [[ $# -gt 0 ]] ; do >>>>>>>>>>>>>> + case "$1" in >>>>>>>>>>>>>> + --no-log ) rpzLog=3D"no" ;; >>>>>>>>>>>>>> + --no-reload ) ucReload=3D"no" ; checkConf=3D"no" ;; >>>>>>>>>>>>>> + esac >>>>>>>>>>>>>> + shift # Shift after checking all the cases to get next = option >>>>>>>>>>>>>> +done >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +case "${rpzAction}" in >>>>>>>>>>>>>> + # add new rpz list >>>>>>>>>>>>>> + add ) >>>>>>>>>>>>>> + check_name "${rpzName}" # is this a valid name? >>>>>>>>>>>>>> + # does this config already exist? If yes, then exit >>>>>>>>>>>>>> + if [[ -f "${rpzConfig}" ]] ; then >>>>>>>>>>>>>> + msg_log "error: rpz: duplicate - ${rpzConfig} already = exists. exit" >>>>>>>>>>>>>> + exit 104 >>>>>>>>>>>>>> + fi >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + # is this a valid URL? >>>>>>>>>>>>>> + = regex=3D'^https://[-[:alnum:]\+&@#/%?=3D~_|!:,.;]*[-[:alnum:]\+&@#/%=3D~_|= ]' >>>>>>>>>>>>>> + if ! [[ "${rpzURL}" =3D~ $regex ]] ; then >>>>>>>>>>>>>> + msg_log "error: rpz: the URL is not valid: = \"${rpzURL}\". exit." >>>>>>>>>>>>>> + exit 105 >>>>>>>>>>>>>> + fi >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + # create the zone config file >>>>>>>>>>>>>> + { >>>>>>>>>>>>>> + echo "rpz:" >>>>>>>>>>>>>> + echo " name: ${rpzName}.rpz" >>>>>>>>>>>>>> + echo " zonefile: ${rpzFile}" >>>>>>>>>>>>>> + echo " url: ${rpzURL}" >>>>>>>>>>>>>> + echo " rpz-action-override: nxdomain" >>>>>>>>>>>>>> + echo " rpz-log: ${rpzLog}" >>>>>>>>>>>>>> + echo " rpz-log-name: ${rpzName}" >>>>>>>>>>>>>> + echo " rpz-signal-nxdomain-ra: yes" >>>>>>>>>>>>>> + } > "${rpzConfig}" >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + # set-up zonefile >>>>>>>>>>>>>> + # create an empty rpz file if it does not exist >>>>>>>>>>>>>> + if [[ ! -f "${rpzFile}" ]] ; then >>>>>>>>>>>>>> + touch "${rpzFile}" >>>>>>>>>>>>>> + # unbound requires these settings for rpz files >>>>>>>>>>>>>> + set_permissions "${rpzFile}" "${rpzConfig}" >>>>>>>>>>>>>> + fi >>>>>>>>>>>>>> + ;; >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + # trash config file & rpz file >>>>>>>>>>>>>> + remove ) >>>>>>>>>>>>>> + if ! [[ -f "${rpzConfig}" ]] ; then >>>>>>>>>>>>>> + msg_log "error: rpz: cannot remove ${rpzConfig}, does = not exist. exit" >>>>>>>>>>>>>> + exit 106 >>>>>>>>>>>>>> + fi >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + msg_log "info: rpz: remove config file & rpz file = \"${rpzName}\"" >>>>>>>>>>>>>> + rm "${rpzConfig}" >>>>>>>>>>>>>> + rm "${rpzFile}" >>>>>>>>>>>>>> + ;; >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + reload ) >>>>>>>>>>>>>> + check_unbound_conf "${checkConf}" >>>>>>>>>>>>>> + ;; >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + list ) >>>>>>>>>>>>>> + awk -F':' '/^\s*name:/{ gsub(/[[:blank:]]|\.rpz/, = "",$2) ; NAME=3D$2 } \ >>>>>>>>>>>>>> + /^\s*url:/{ gsub(/[[:blank:]]/, "") ; print = NAME"=3D"$2":"$3} ' \ >>>>>>>>>>>>>> + /etc/unbound/local.d/*rpz.conf >>>>>>>>>>>>>> + exit >>>>>>>>>>>>>> + ;; >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + unbound-restart ) >>>>>>>>>>>>>> + check_unbound_conf "${checkConf}" >>>>>>>>>>>>>> + unbound_restart >>>>>>>>>>>>>> + exit >>>>>>>>>>>>>> + ;; >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + * ) >>>>>>>>>>>>>> + msg_log "error: rpz: missing or incorrect parameter" >>>>>>>>>>>>>> + printf "Usage: $(basename "$0") =