avahi-browse, avahi-resolve crashes avahi-daemon if hostname/service is malformed

[salahx]

Either of the following commands cause avahi-daemon to die (thus, a local DoS), unless --enable-check was selected when dbus was built (on Gentoo, this isn't the default, it has to be enabled by USE="debug")

avahi-browse ssh
avahi-resolve machinename

instead of:

avahi-browse _ssh._tcp
avahi-resolve machinename.local

Also, if avahi-dnsconfd is passed an invalid long command line argument (like --debug), it will segfault instead of printing "Invalid Command Line Argument: --debug". Even if you pass an invalid single-charecter option, it doesn't do what you'd expect either (it just prints a "?" - maybe an unprintable character). Avahi-daemon has a similar issue too (although it doesn't segfault it doesn't do what'd you expect, either). I didn't test the other utilities for this bug.

[lennart]

(In [1234]) properly finish getopt argument table with a NULL entry (see #50)

[lennart]

You must be running a very old version of Avahi. (Which one, BTW?) On my machine I get the following results when running the suggested commands:

1 [lennart@ecstasy] ~$ avahi-browse ssh
avahi_service_browser_new() failed: Invalid service type
2 [lennart@ecstasy] ~$ avahi-resolve machinename
No command specified.
3 [lennart@ecstasy] ~$ avahi-resolve-host-name machinename
Failed to create host name resolver: Invalid host name

The avahi-dnsconfd command line parsing is now fixed (thank you for reporting).

The "?" is default getopt() behaviour and not a problem. The test utilities are not vuilnerable to the segfault issue.

[lennart]

(In [1235]) work around a limitation in Gentoo's DBUS build (which is compiled with --disable-checks): never try to unregister non-existing object paths from DBUS. (closes #50 - this time for sure)