(Disclaimer: I am not an Ubuntu user myself. But I happen to be the lead developer of Avahi.)

It came to my attention that Ubuntu is discussing whether to enable Zeroconf/Avahi in default installations. I would like to point out a few things:

The "No Open Ports" policy: This policy (or at least the way many people interprete it) seems to be thought out by someone who doesn't have much experience with TCP/IP networking. While it might make sense to enforce this for application-level protocols like HTTP or FTP it doesn't make sense to apply it to transport-level protocols such as DHCP, DNS or in this case mDNS (the underlying protocol of Zeroconf/Avahi/Bonjour):

• Even the simplest DNS lookup requires the opening of an UDP port for a short period of time to be able to recieve the response. This is usually not visible to the administrator, because the time is too short to show up in netstat -uln, but nonetheless it is an open port. (UDP is not session-based (like TCP is) so incoming packets are accepted regardless where they come from)
• DHCP clients listen on UDP port 68 during their entire lifetime (which in most cases is the same as the uptime of the machine). DHCP may be misused for much worse things than mDNS. Evildoers can forge DHCP packets to change IP addresses and routing of machines. This is definitely something that cannot be done with mDNS.

All three protocols, DNS, DHCP and mDNS, require a little bit of trust in the local LAN. They (usually) don't come with any sort of authentication and they all are very easy to forge. The impact of forged mDNS packets is clearly less dangerous than forged DHCP or DNS packets. Why? Because mDNS doesn't allow you to change the IP address or routing setup (which forged DHCP allows) and because it cannot be used to spoof host names outside the .local domain (which forged DNS allows).

Enforcing the "No Open ports" policy everywhere in Ubuntu would require that both DNS and DHCP are disabled by default. However, as everybody probably agrees, this would be ridiculous because a standard Ubuntu installation couldn't even be used for the most basic things like web browsing.

Oh, and BTW: DNS lookups are usually done by an NSS plugin which is loaded by the libc into every process which uses gethostbyname() (the function for doing host name resolutions). So, in effect every single process that uses this function has an open port for a short time. And the DNS client code runs with user priviliges, so an exploit really hurts. dhclient (the DHCP client) runs as root during the entire runtime, so an exploit of it hurts even more. Avahi in contrast runs as its own user and chroot()s.

It is not my intention to force anyone to use my software. However, enforcing the "No Open Ports" policy unconditionally is not a good idea. Currently Ubuntu makes exceptions for DHCP/DNS and so it should for mDNS.

I do agree that publishing all kinds of local services with Avahi in a default install is indeed problematic. However, if the "No Open Ports" policy is enforced on all other application-level software, there shouldn't be any application that would want to register a service with Avahi.

Starting Avahi "on-demand" is not an option either, because it offers useful services even when no local application is accessing is. Most notably this is host name resolution for the local host name. (Hey, yeah, Zeroconf is more than just stealing music.)

Remember: Zeroconf is about Zero Configuration. Requiring the user to toggle some obscure configuration option before he can use Zeroconf would make it a paradox. Zeroconf was designed to make things "just work". If it isn't enabled by default it is impossible to reach that goal.

Oh, and I enabled commmenting in my blog, if anyone wants to flame me on this...

Yesterday my brother released his second Free Software package, the SECCURE Elliptic Curve Crypto Utility for Reliable Encryption. (Recursive acronyms, yay!)

The seccure toolset implements a selection of asymmetric algorithms based on elliptic curve cryptography (ECC). In particular, it offers public key encryption / decryption and signature generation / verification. ECC schemes offer a much better key size to security ratio than classical systems (RSA, DSA). Keys are short enough to make direct specification of keys on the command line possible (sometimes this is more convenient than the management of PGP-like key rings). seccure builds on this feature and therefore is the tool of choice whenever lightweight asymmetric cryptography -- independent of key servers, revocation certificates, the Web of Trust, or even configuration files -- is required.

Anyone willing to work on the Debian RFP?

(The first Free Software package of him is ssss, an implementation of Shamir's secret sharing scheme)

Marc-Andre was so kind to upload the improvised mini-slides we had prepared for GUADEC's sound BOF. Unfortunately there is no recording of the BOF, so this is all we can offer for those interested but who were not able to attend GUADEC.

In related news: Thanks to jat there is now a native PulseAudio driver for MPD (in SVN), and I updated the MPlayer patch, which adds a native PulseAudio driver to MPlayer.

Diego and others who complained: PulseAudio in SVN now uses Avahi natively for ZeroConf. The old HOWL based code has been removed.

davidz: Shams King is currently working on HAL support in PulseAudio. He's planning to extend our module-combine to automatically combine all available hardware sound cards found with HAL into a single virtual sound sink. That way, if the user plugs in an USB loudspeaker set it will automatically output the same audio as the internal speakers did before. I believe this is the behaviour most non-technical users would expect from a well designed system.

Right now PulseAudio sink names cannot be used to identify the underlying hardware devices, since they are generic names like alsa_output or oss_output2. However, it might be a good idea to use the ALSA device name (i.e. alsa_output_hw_0_0) or even the HAL identifier if it is available. If this dialog uses the normal GStreamer PropertyProbe API to query the available devices (and does not use HAL directly), we should be able to support this easily in gst-pulse (right now we support this interface in GstPulseMixer, but not yet in GstPulseSink).

Marc-Andre, I wonder how the differentiation between "Sound events", "Music and Movies" and "Audio/Video Conferencing" touches the "role"/"class" model of GSmartMix?

Regarding power saving and PulseAudio: First of all, PulseAudio right now is intended to be run per-session, just like esd was. However, there is some incomplete support for running it as system-wide instance.

I think instead of integrating PulseAudio with gnome-power-manager the way you described it is probably a better idea to close the sound device when it is idle regardless if we are in power saving mode or not, and hope that the driver authors fix their stuff to not produce any click or pop sounds when the device is opened or closed. To be honest, all driver/sound card combinations I have access to work properly in this area.

In ALSA you usually open devices in O_RDONLY or O_WRONLY mode (and not in O_RDWR) anyway, so falling back to it is not really necessary.

We're proud to announce the first release of PulseAudio after the name change from Polypaudio. Besides a variety of sed -i -e s/polyp/pulse/g changes it mostly contains minor bugfixes. Get it while it is hot!

In related news PulseAudio now gained its own domain and a new Trac-based homepage: http://pulseaudio.org/. And thanks to Rafael Jannone and Pierre Ossman we now have a logo:

Together with PulseAudio 0.9.2 we released updated versions of all the auxiliary GUI tools. A new utility has been released as well, named PulseAudio Device Chooser. It installs a tray icon and allows the user to quickly change the sound server attached to the local X11 display, showing a list of servers that is accumulated using ZeroConf service browsing. In addition it allows you to quickly start one of the other GUI tools and shows notification whenever a new PulseAudio server/sink/source appears on the network. Everybody loves screenshots:

There has been some confusion about the date of the Sound BOF, since the BOF Wiki said a different date than my blog story of yesterday. To make this clear: the BOF will happen on friday, 4 p.m.

There will be a Linux/Gnome Sound BOF on Friday, 4:00 p.m. I will be there, promoting PulseAudio, as will be Marc-Andre of GSmartMix frame. Everyone interested in the future of audio in Gnome is welcome to join us!

Due to the generosity of the GNOME Foundation I have been able to get to the GUADEC 2006 this year. I'd like to thank Jeff Waugh and Quim Gil for the "last-minute" funding of my trip to Vilanova, and all the sponsors who actually are providing the funds. If anyone wants to talk to me about Avahi and/or PulseAudio (aka Polypaudio) (or any of my other projects), just try to find and speak to me. (Bungalow 870)

In related news, the new PulseAudio homepage will be "inaugurated" soon, becoming the official new home of PulseAudio/Polypaudio as soon as we release 0.9.2, which hopefully will be pretty soon.

It came to our attention that some people really disliked the name of Polypaudio, because it reminded them of that medical condition, though the software was actually named after the sea dweller. I actually liked that double entendre, but many did not and expressed concerns that the name would hinder Polypaudio's adoption. After a long discussion on #polypaudio we came to the conclusion that a name change is a good idea in this case. Name changes are usually a bad idea, but this time it's worth it, we think.

The new name we agreed on is PulseAudio, or shorter just Pulse. It has the nice advantage that it abbreviates to pa, just as Polypaudio did. This allows us to keep source code compatiblity (and binary compatibility to a certain degree) with the current releases of Polypaudio, because the symbol prefix can stay pa_. In addition the auxiliary tools paman, pavucontrol, pavumeter need not to be renamed.

We will try to make the transition as smooth as possible and would like to apologize to all the packagers, who need to rename their packages now.

The next release of Polypaudio (0.9.2) will be a bugfix release and be the first to bear the new name: PulseAudio 0.9.2.

Polypaudio is dead. Long live PulseAudio!