From owner-freebsd-security  Sun Jun 23 09:07:39 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id JAA05224
          for security-outgoing; Sun, 23 Jun 1996 09:07:39 -0700 (PDT)
Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA05215;
          Sun, 23 Jun 1996 09:07:34 -0700 (PDT)
Received: (from alex@localhost) by zen.nash.org (8.7.5/8.6.12) id LAA07941; Sun, 23 Jun 1996 11:05:36 -0500 (CDT)
Date: Sun, 23 Jun 1996 11:05:36 -0500 (CDT)
Message-Id: <199606231605.LAA07941@zen.nash.org>
From: Alex Nash <alex@zen.nash.org>
To: nate@sri.MT.net
Cc: freebsd-security@FreeBSD.org, gpalmer@FreeBSD.org, taob@io.org,
        phk@FreeBSD.org
Subject: Re: IPFW documentation
Reply-to: nash@mcs.com
Sender: owner-security@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> > :(  Unfortunately not.  When I submitted my ipfw changes into -current,
> > my understanding was that 2.1.5 was about 2 weeks from being solidified.
> > The dilemma was whether I should risk bringing in mass changes into
> > -stable.  After discussing this with Poul, I decided against doing so.
> 
> I *sort of* agree.  The problem is that both the man pages and the
> documentation we have is *wrong* and out of date.  There have been
> *many* changes made to both the kernel and user-land code, but there
> has been *NO* documentation of it.
>
> >From /sys/netinet/ip_fw.c
> revision 1.14.4.7
> date: 1996/05/06 20:32:01;  author: phk;  state: Exp;  lines: +18 -14
> Merge from head.
> 
> >From ipfw.8
> revision 1.7.4.6
> date: 1996/02/26 15:26:59;  author: phk;  state: Exp;  lines: +194 -29
> Update to lates reality.
>
> We've got a problem here.
> 
> I consider this a *bug*, and a critical one at that, especially given
> our potential customer base.  The people most likely to use 2.1.5 are
> ISP's and such, who have both a need and a desire for the functionality
> of IPFW.

I agree with your last statement 100% (in fact this came up in my
discussion with Poul).  But since I didn't know exactly when -stable would
freeze, I was very concerned that I might introduce a problem that would
end up getting shipped in 2.1.5.  In retrospect, I should have bit the
bullet and just done it.

> > -stable has all the latest bug fixes, but lacks the updated
> > documentation.  I'm sitting on some handbook changes because I didn't
> > want the handbook to *seem* up to date, but really only cover -current.
> 
> What about the man-pages & the stuff in /etc?  Are they correct and up
> to date?  Even if the handbook stuff isn't correct, the on-line stuff
> should at least be somewhat correct.

No argument here :)

> > If anyone has suggestions on where we should take -stable, I'd be
> > happy to hear them.  If it looks like 2.1.5 will be delayed long
> > enough, we can see about bringing -stable up to the level of -current.
> 
> We have until Tuesday to get things at least somewhat 'sane'.  Please
> can you take the time to document what exists in -stable!?!?

You bet.  How about this:

  - Bring src/sys/netinet/ip_fw.c up to -current level (or very
    close to).

  - Bring src/sbin/ipfw/ipfw.c in line with the kernel changes.

  - Try and get the man page in shape (the version in -current is
    a lot closer, but not perfect).

(The handbook may have to lag a bit, sorry :( )

When this is done, I'll announce where patches can be found so that as
many people as possible can bang on it to make sure it's ok.  That'll
give me the comfort level I'd need to place these changes into 2.1.5.
Does this sound viable?

Alex