Darren Reed wrote:
> > I think you misunderstand what his change did.
> 
> It effectively disabled the software for everyone using it on -current.
> And did so "quietly".

Yes. And, I think the "but you're running -current" thing is somewhat of
a red herring. Let's say JS was running a 1.2(.1) machine with add-on
ipfilter, and the upgraded to 1.3 in the future. He still loses in that
case, without running -current. And he probably would have had even less
of a chance not to, because he's less likely to have been reading
current-users or source-changes if he's not tracking current on at least
one machine. Is his setup still too fragile?

If the default is going to be changed, I can live with needing a kernel
option to restore the old default. But the 1.3 (or any intermediate
snapshot) install notes had better say, right up front in as
attention-grabbing a format as possible, that the default has changed.
I'm less concerned about what the default is (though I would prefer a
default-secure, myself) than the fact that this is a danger of being a
silent change for people. Especially in a system component specifically
designed for security, a silent change to a less secure state by default
is a very scarey thing.

For that matter, while people often say "don't run current on a
production machine", and while that's a very valid point in many cases,
the fact is is that there is much better support for current than formal
releases in a number of ways, especially in terms of the effort to keep
those who only run formal releases informed(*), short of making them
read current-users and source-changes.  Now, I rather enjoy reading them
-- source-changes is my favorite of all the mailing lists of any type
that I'm on (**).  But for some people, this is a problem.

[(*) I don't necessarily say that this can really be improved in a
volunteer effort such as this or that this is anyone's fault, I'm only
pointing this out because I feel those who point people to formal
releases as a complete solution need to think it through a little more,
in many cases.  I also happen to know that many of the people I've see
say "you shouldn't use -current on a production machine" are in fact
guilty of this themselves. I'll admit I'm one of them.

(**) Yes, I do need to get a life. Thank you for asking. :-)]

> Whilst he added some bits to /etc/netstart, I'm inclined to believe that
> people update that much less often than they do kernel source.

Especially since it's a royal pain (though it's getting much better of
late -- thanks to those working on this problem)

> Anyway, I've been reading what people are saying I'm more inclined to add
> "IPFILTER_NOAUTO_ENABLE" (rather than "IPFILTER_AUTO_ENABLE") as the former
> (if missing) is consistant with IP Filter's current behaviour elsewhere and
> revert the behaviour to not need an explicit "ipf -E".

This sounds better to me.  That option could even be put in GENERIC
kernels, to keep new users happy.  Hopefully when/if they install
ipfilter rules, they'll check to make sure they work, and notice then
the need to remove the option or add ipf -E, if not sooner. 

> I'll be certain to try find some way of making sure people are aware of its
> status when it "attaches", either way.

That is an excellent idea.  Also, we could perhaps have a setting for
the correct state (enabled or disabled) in /etc somewhere, not to set
the option, but to check if the kernel is defaulting to the expected
value.  That way, if you accidentally run a default-open kernel on your
default-closed firewall, /etc/rc can print a warning and either halt or
do ipf -E (configurable).  In the opposite case, it can print a warning
and keep going.