severity 392590 important thanks On Thu, Oct 12, 2006 at 02:29:12PM +0200, Christoph Martin wrote: > Package: zeroconf > Version: 0.9-1 > Severity: critical > Justification: breaks unrelated software
> on recent updates to testing of some of my systems zeroconf > was installed because of recommends of other packages (kde etc.) > Like other users have already reported this resulted in an *additional* > IP-address assigned to the primary network interface as a link local > address. Yes, this is what the software does. > Since the user never directed the update to reconfigure the network > setting, this is a policy violation. No, it is not. > The default of the zeroconf settings should be, either "do never configure > the add hoc ip address" or "only configure the add hoc ip address if no ip > address is configured for this interface". Both of these defeat the purpose of zeroconf. > The problem with the additional ip address is unexpected behaviour of > unrelated software. > With the two ip addresses the machine broadcasts with two different > addresses. This might result in alarms in the network, because a machine > comunicates with the wrong address. This might also result in the > disabling of the machine on a switch which sees the wrong address (cisco > catalyst dhcp-snooping). This is not the meaning of "unrelated software". It apparently makes zeroconf unsuitable for your *environment*, but that's not a bug that can be fixed in zeroconf -- this is what zeroconf *does*. > Some programs rely on the configured and allowed ip address to operate. > If now one machine responds on a different address because it can also > reach the other machine with it, we get a problem. We have one report > that ssh reports a security warning, because a key is recorded with a > different ip address. So you have multiple machines on your local link that are running zeroconf (or similar technology), as a result they can talk to each other using local link addresses, and this is inconsistent with the policies in your environment. Ok, so you will apparently not want to use zeroconf in your environment, or you will need to reconsider the correctess of your policies. Again, not a bug in zeroconf, which is working as designed. > Services using tcpwrappers get configured with ip addresses. These > services will sometimes fail because they use the wrong addresses. ditto. > Some programs will not bind to the wildcard any address but to all ip > addresses they find (like ntp, sendmail, bind etc.). This will result in > at least additional warnings in syslog etc. Doesn't justify an RC bug. > if not in malfunction. if the program only configures the first address > for one interface it will probably break. Those would be bugs in those other programs, not in zeroconf. > These are only some of the problems I have detected. None of them are release-critical. I'm downgrading the bug; were I the maintainer, I would probably close it. > You could introduce debconf questions or just make the default > configuration disabled or fallback. I don't think it's justified to demand such a default; I don't believe this optimizes for the common case. Thanks, -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
