= Main Inclusion Report for `avahi` =

 0. ''Availability:'' Available in universe/experimental, Arch: any; FTBFS on i386
 0. ''Rationale:'' used by rhythmbox for automatic music sharing (DAAP), can be used by gnomevfs for browsing of services
 0. ''Security:'' 
  * No CVEs
  * Source code review: `avahi_new` does not check for int overflows, but no actual vulnerabilities ATM; upstream was contacted about this
 0. ''Quality assurance:''  
  * Important Debian bugs should be solved in Ubuntu
  * 2 normal bugs on https://bugs.freedesktop.org/
 0. ''Standards compliance:'' 
  * The package meets the FHS.
 0. ''Dependencies:'' 
  * libdaemon 
  * qt4-x11 (MainInclusionReportQt4, deactivated for now) 
  * xmltoman(binary) from universe

== Reviewers ==
MartinPitt: approved

== Security Assessment by avahi developers ==
A few notes on the security implications of Avahi:

 0. Avahi properly drops priviliges, enforces resource limits and chroot()s itself. Needless to say this is much more than most programs currently available in Ubuntu/main do. Please note that to work properly in a chroot() environment avahi forks off a small helper daemon which lives outside the chroot(). It provides access to some static data files (notably DBUS introspection data) and to PID files. Communication between the main daemon and the helper daemon is limited to the minimum verbosity needed. We use single-byte commands to request an action from the helper daemon. In response a single byte is sent, possibly accompanied by a (read only) file descriptor. The chroot() process has four ways to contact the system outside the chroot(): firstly there's normal network access (port 5353, UDP), secondly there is the chroot helper process, thirdly there is the DBUS interface, and finally there is the UNIX socket which may be used to contact the NSS module.
 0. All network input is validated before it is actually processed.
 0. The same is true for the DBUS interface. In addition to the basic validation the DBUS library imposes by itself we validate all user arguments and provide an elaborate error reporting facility to report the exact failure cause back to the user
 0. All error conditions are handled properly. We use a lot of asserts to make sure that everything works as intended.
 0. Though Avahi is actually quite popular these days, we only had a single security sensitive bug. (And almost no other bugs.) The bug triggered an assert (i.e. it allowed a simple DoS attack) and could not be exploited in a way that code could be smuggled into the process.
 0. The Avahi daemon aborts on OOM. However the client library deals with OOM situations properly and returns this as normal error code.
 0. Fedora now moved Avahi from "extras" to "core", so i guess it is good enough for them. (BTW: they provide an SElinux policy file for avahi which can be used to make avahi even more secure)
 0. Certainly, Avahi *will* have bugs, but I believe that it has a lot less bugs than many of the other software available in Ubuntu/main.
 0. Please keep in mind that Avahi is mostly used in local area networks and that it ignores traffic from non-local networks.
 0. We pass Apple's Bonjour conformance tests without exceptions (which includes a lot of tests to make sure that Avahi will not flood your network). Please note, however, that mDNS is not fully "flooding-proof". This is by design of the protocol and is justified by the Apple people with the fact that mDNS is not an internet protocol but a LAN protocol.
 0. Much more security sensitive than Avahi is nss-mdns (which is loaded into every process using gethostbyname()). However, Avahi does not rely on nss-mdns to be useful. You might consider supporting Avahi but not nss-mdns for the near future. (Though nss-mdns is actually tiny in contrast to Avahi)
 0. A dead Avahi daemon will not make the system unstable or vulnerable in any way (at least if all clients are written cleanly).
 0. For more information, feel free to contact one of the Avahi developers

Lennart Poettering