[ Please respect the list code of conduct; I don't request CCs, nor does ]
[ my M-F-T get set as such. In other words, don't send them. ]
On Thu, Mar 17, 2005 at 12:16:27AM -0800, Thomas Bushnell BSG wrote:
> Joel Aelwyn <fenton@debian.org> writes:
>
> > Fine, if you want to get pedantic, the following is a bare minimum of
> > capabilities I would expect from any network processing on a 'real'
> > (non-toy) network stack, where 'network stack' means everything between
> > hardware driver and delivery of data to a userland application. It's late,
> > so this may not be exhaustive.
>
> The guidelines do not speak of "toy os". It appears that you are not
> aware of why this requirement is listed in the guidelines, nor of why
> it would be important for the secondary archive, nor of what the
> actual practice is on buildds.
>
> Can we replace this with a thread involving people who do know these
> things?
>
> The Hurd has had all the things listed on your schedule of filtering
> rules for longer than Linux has. All that is necessary is simple
> user-space tools to implement them. Do you have a specific tool that
> should run, or anything else?
If you have all of the filtering rule support, then why is this even an
issue? Write the user-space tool and you should be golden; you've got a
useable firewalling implementation.
What's the problem?
> > Unless marked as 'nice to have', everything above is a *must* for running
> > even basic firewall configurations on a host expected to face the Internet.
> > If you can do those, and configure them in some semi-sane fashion, then
> > you probably meet the expectations reasonable people would have for "basic
> > firewalling".
>
> But what is not said here is why this particular feature is necessary
> for being in the secondary archive, as opposed to other features.
>
> To say, "a buildd must have that feature" is only sensible if the
> buildds are actually *using* such-and-such feature, and you, in fact,
> don't know that they are.
Allright, since your other email said it didn't have to be hooked up to the
w-b network, and seemed to miss the point:
To be sane to administer a system which is exposed to general Internet
traffic, including through a NAT or other proxy, it is important to be able
to control the policy for what traffic is actually passed to the userspace
applications, or routed to another network on router-capable OSes (note
that being able to route is not, AFAIK, a buildd requirement),
That means firewalling capabilities. It's flat ****ing insane to expect DSA
folks to try to keep a system secure if it doesn't have basic firewalling.
It's that simple, and it's backed by a couple of decades of best common
practice by both network and systems administrators.
If you want to avoid this situation, then I suggest you explain how you
intend to get things needing build from incoming to your buildd, and the
results back to incoming.
But you say you have this capability already, perhaps modulo userspace
tools to configure it. So get someone to bang them out, and you should
be good to go (or, heck, get the existing firewall config tools to
support whatever you use to configure this, if they aren't excessively
Linux-centric; at the very least, a workalike interface is a good place to
start).
--
Joel Aelwyn <fenton@debian.org> ,''`.
: :' :
`. `'
`-
Attachment:
signature.asc
Description: Digital signature