On Fri, Nov 25, 2005 at 12:19:58PM +0100, Johannes Wiedersich wrote: > >On Fri, Nov 25, 2005 at 10:26:43AM +0100, Johannes Wiedersich wrote:
> >>Subject: firestarter breaks nis > >>Package: firestarter > >>Version: 1.0.3-1.1 > >>Severity: critical > >>Justification: breaks unrelated software > >Firestarter is a firewalling tool; nis is a network application. These are > >not unrelated software. > >Given that you can break *any* network application by means of a > >misconfigured firewall, and given that your stated solution for this bug > >was > >to make a change to your *nis* config, not to your firestarter config, I > >don't see any reason to treat this as a grave bug, either. > This is a workaround, not a solution. > In fact installation/start of firestarter breaks an otherwise working > configuration in nis. The really annoying part of the problem is that no > hints of what gets wrong is displayed by firestarter; no events etc. > The firewall is set up correctly, allowing all connections to the > desired private network. I would prefer to change the configuration via > firestarter, not nis. How should one set up firestarter to allow > broadcassting to 192.168.0.255 for a nis server apart from allowing all > connections to and from 192.168.0.0/24? Presumably, allowing outbound broadcast packets to 192.168.0.255/32 on an appropriate destination port and incoming udp packets from 192.168.0.0/24 on an appropriate source port would be correct? I've never personally used firestarter, so I don't know whether it's reasonable to expect all blocked inbound or outbound packets to generate logging events. The package description says there's a "real-time hit monitor" that shows attackers probing your machine; if it's the outbound traffic that's being blocked, then that doesn't qualify as "an attacker probing the machine", so *I* don't have any expectation that such traffic would generate log events. You may have a different expectation; if so, it would help me to know why your expectation is different from mine. > To sum it up: the firewall is configured correctly, This is patently false. If the firewall were configured correctly for your application, the application would not fail. If you mean that the firewall *cannot* be configured correctly, that would be a more serious bug, but I haven't gathered that this is actually what you're saying. > shows no logs which could warrant a release-critical severity, depending on what the normal logging policy is for firestarter. > NB: According to reportbug: > breaks unrelated software: breaks unrelated software on the system > (packages that have a dependency relationship are not unrelated) > I used this definition of 'unrelated'. Sorry if this was wrong. This is not a definition, this is only an explanation of one type of package relationship that *disqualifies* a bug for being of critical severity. :) Software may be "related" in other ways than through dependency fields -- like I said, a firewall and a network application are another case of related packages. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
