site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XAokbvnkkpgeQkf3KlcRndTRMruZ1fDIV2ZPLrCVMSFiM7gXAZbWehDo6iRndIvo; h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; On May 17, 2006, at 3:48 PM, Terry Lambert wrote: Best regards, Chris _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This is not actually true. There are a number of approaches to dealing with this, but taking over a single entry point rather than muxing it is definitely *not* the way to play nice with other software. Whatever approach you use *must* be amenable to being daisy-chained. The concern about leaving intact all the tools from other kits (altq, NAT, etc.) is that if not replaced, software that doesn't know about the pf-related system and how to interact with it will merely bollux up the system rather than experience harmless but informative failure (ie, the binaries that drive ipfw aren't there to be used, rather than that they or a duplicate are there and pretend to do the right thing but likely don't because of differences between the underlying system and the userland tools by which they are driven and from which one receives reports). The idea behind the pf system is to give more power (per-connection priority and not just per packet; address translation in the same place as the filtering so that managing connections involving translated IP addresses and redirections to different interfaces don't do unexpected things; faster handling of complex rule sets; genuine statefulness), and leaving alternate "solutions" for these things risks enabling multiple inconsistent methods of skinning various in-kernel cats, after the cat-breeder has gone to, say, leapords. I can imagine why one might want to include wrappers for folks who use tools that expect old FreeBSD parts to be there ... but there won't be a 1:1 relation between what the pf system does and what can be revealed by a old-compatible-lookalike wrapper. Where confusion is the likely result of maintaining some semblance of backward compatibility with prior tools, isn't clear and immediate failure a better option? Daisy-chaining works great with pf, just ... daisy-chaining a system involving pf with tools that think they're talking to ipf, ipfw, iptables, or the like is surely a road to madness, no? Assuming this hasn't been rendered moot by source unavailability on Apple's future platforms, is there an appropriate place to inquire whether efforts to make security and administration improvements (eg: pf, systrace) will be viewed favorably or will be rejected out of hand and thus should not attract effort? This email sent to site_archiver@lists.apple.com