Oh, I see. This is still a problem for exit... hmm. > On 27. Nov 2019, at 12:37, Schanzenbach, Martin <[email protected]> > wrote: > > Hi, > > my take would be that limiting this functionality to Linux for now is > perfectly fine as there are other options (e.g. local DNS server > configuration). > > BR > Martin > >> On 27. Nov 2019, at 12:15, ng0 <[email protected]> wrote: >> >> You are right, libpcap does not allow what we require. >> >> I'm still reading into it, but can we add a packet filter neutral >> (or not using any packet filters at all) version to the requirements >> of a stable GNUnet? What I describe below doesn't scale very good. >> >> The two helpers right now require iptables. >> pf implementations on *BSD differ by syntax. >> Other systems most likely use a different packet filter. >> iptables could change / be on its way out in the future (see eBPF in Linux >> and its recent development directions). >> >> Even for iptables this means we have to keep up with changes. >> >> Right now, every porter would have to add a block for the packet filter >> of their operating system. >> As someone more knowledged about this wrote yesterday "hoping for >> compatibility >> between firewalls seems like a plan doomed to fail". >> >> Do I follow this course for now (adding system specific firewalls), or >> do we have another option in the near/far future for these helpers? >> >> it's really unpleasant for adding and maintaining systems support beyond >> Linux for this part. and even Linux will change at some point, >> so we need to move to whatever firewall has replaced iptables again >> (a new nftables? idk). OpenBSD's pf syntax changes slowly, but sometimes >> it changes. Other pf syntaxes change as well. I'm not sure about other >> firewalls and how they developed over time, but it is unlikely they >> didn't change. >> >
signature.asc
Description: Message signed with OpenPGP
