Please add module-raop-discover and module-zeroconf-discover to default.pa

As well, I think paprefs only goes a little toward resolving this issue.

Paprefs is not installed by default and forcing people to install it before they can use remote audio introduces a non-obvious step.

Daniel, out of interest, what are the downsides of adding this configuration stanza? Would it put too much overhead on PA's startup?

My perception is that adding it contributes fairly negligible overhead. The questions are:

1) Are there any security-related downsides to have them enabled by default?
2) Is this an often-requested feature?

Fortunately the former is easier to address than the latter (i.e., it could just be enabled). I'm certainly in favor of having it enabled, but I'm not well-acquainted with the former.

While I am not familiar with the internals of PA, my perception would be that:

1) Enabling those modules would simply make remote audio sinks browsable by the local user. As such, I cannot see how it could cause any security issue.

2) By contrast, publishing local sinks to the outside world could open the door to remote exploits.

Daniel T Chen [2010-12-11 22:00 -0000]:
> 1) Are there any security-related downsides to have them enabled by default?

This sounds very similar to having Avahi enabled in general. The
Ubuntu policy allows service discovery (DNS-SD, DHCP, SNMP, etc.) to
be enabled by default, as they merely identify remote services.
Security will come into play when actually connecting to those remote
services, but that sounds separate from those modules?

I was mainly curious why you closed the bug; I think it's a legitime
wishlist item.

Thanks!

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Ah, so the Status should be Triaged instead of Opinion?

Daniel T Chen [2010-12-11 22:39 -0000]:
> Ah, so the Status should be Triaged instead of Opinion?

Unless there is a good reason to not fix this, I think that's better.
"Opinion" more or less means "won't fix" and is a closed state.

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Even though the original config fragment I proposed above should work, it seems that under specific circumstances, on some of my test hardware, loading the modules in that order fails. Additionally, unless I'm mistaken, it seems tat RAOP depends upon Zeroconf, so perhaps the following config segment would be safer:

.ifexists module-zeroconf-discover.so
.nofail
load-module module-zeroconf-discover
.fail
.endif
.ifexists module-raop-discover.so
.nofail
load-module module-raop-discover
.fail
.endif

Thanks for testing; I'll commit this change tonight if no one beats me to it.

This bug was fixed in the package pulseaudio - 1:0.9.22+stable-queue-18-geb966-0ubuntu1

---------------
pulseaudio (1:0.9.22+stable-queue-18-geb966-0ubuntu1) natty; urgency=low

  [ Daniel T Chen ]
  * debian/control: pulseaudio-module-zeroconf Depends on avahi-daemon
    (LP: #689093)
  * debian/patches/0101-update-stable-queue.patch: Apply 84c8b23c to
    resolve incorrect header being used for libsndfile seen with pacat
    --file-format (LP: #660504)
  * debian/patches/0104-Load-RAOP-Zeroconf-by-default.patch: Follow
    recommendation by Martin-Éric Racine to conditionally load support
    by default for streaming to an Apple Airport Express (LP: #688272)
  * debian/pulseaudio-utils.links: Also add pamon(1) and parecord(1)
    (Closes: #599696)

  [ David Henningsson ]
  * debian/pulse-alsa.conf: Add name hint for default pcm device,
    indicating that PulseAudio is active.

  [ Luke Yelavich ]
  * New upstream snapshot based on the stable queue branch:
    - eb966f7 (build-sys: Make --disable-dbus actually work.)
    - 8f8d247 (build-sys: Mention dbus support in the summary)
    - b3ff4f4 (build-sys: Put in specific warnings when there is no udev or
              DBUS support)
    - 862bbee (console-kit: Console Kit support is dependent on DBUS and is
              thus optional.)
    - 7cb1401 (padsp: wrap __open_2 and __open64_2)
    - 6f870f5 (fix bug about get source-output status)
    - 4269b05 (Fix typos)
    - 1c83b03 (Further clarify src- and speex- references in pulse-daemon.conf)
    - 84c8b23 (Fix return value of pa_sndfile_format_from_string)
    - d963b86 (core: Fix variable "has_whined" value bug)
    - 52e3268 (trivial: Mention speex as a resampler reference in
              pulse-daemon.conf)
    - 3e6af07 (module-loopback: Prevent an infinite loop when rate adjusting
              is disabled
  * 0101-update-stable-queue.patch and
    #0102-autoreconf.patch:
    - Disable for now, since latest stable queue are roled into the snapshot
      tarball
 -- Luke Yelavich <email address hidden> Fri, 14 Jan 2011 10:03:49 -0600

I just installed a fresh Natty Alpha 3 netbook. The -raop module package was not installed by default. I had to apt-get install pulseaudio-module-raop before this would work.

To fix bug #688272, PulseAudio started depending on
pulseaudio-module-raop. I'm proposing reverting to the earlier state,
for these reasons:

* It has already caused these bugs:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/742281
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/743073

* According to coling it gives "choppy" sounds

* It is not recommended by upstream:

<diwic> coling, as a downstream disto manager, do you recommend we
enable this module in it's current state (in 0.9.22)?
<diwic> i e the RAOP module
<coling> diwic, what do you mean by "enable"?
<coling> diwic, IIRC it's not enabled by default. You have to turn it on
in paprefs.
<diwic> coling, as in loading module-raop-discover.so in
/etc/pulse/default.pa ?
<coling> diwic, no,
<coling> diwic, but I wouldn't do that even if the module was nicer.
<coling> diwic, it's a paprefs thing, not a default.pa thing - just like
RTP and network protocol.
<diwic> coling, ok, seems it was recently enabled due to a user request
<coling diwic, you mean hacked into default.pa?
<diwic> coling, yup
<coling> Weird.
<coling> If anything, just tweak the gconf schema, rather than default.pa :)
<coling> But I defo wouldn't for ROAP anyway. It's not a very "good
citizen" as it'll hog the airport and not let any other machine use it.
<coling> One day that will be fixed :)

--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

I'm fine with going with the upstream recommendation and disabling it by default. Can we instead document how to enable it, either with a comment in default.pa, or is there an option in paprefs?

Or even better, as the default.pa change is already "if"ed, why not simply drop the pulseaudio-module-raop Depends: from pulseaudio and make it a suggests? Then merely installing the package would enable it, right?

@pitti, good idea - but I'm not sure what that means for zeroconf, so how about pulseaudio-module-raop to have a post-install script to "tweak the gconf schema" as coling suggests?

On Mon, Mar 28, 2011 at 6:21 PM, Martin Pitt <email address hidden> wrote:
> Or even better, as the default.pa change is already "if"ed, why not
> simply drop the pulseaudio-module-raop Depends: from pulseaudio and make
> it a suggests? Then merely installing the package would enable it,
> right?

This change (demoting to Suggests) sounds sane.

1) default.pa already uses a pair of #ifdef so it doesn't need to be fixed.
2) -zeroconf would ideally appear as Depends or Recommends.
3) -raop can be demoted to Recommends or Suggests if it's really causing problems.

> 1) default.pa already uses a pair of #ifdef so it doesn't need to be fixed.

What happens if the user still enables the module in paprefs - will it be loaded twice? Cause problems?

> 2) -zeroconf would ideally appear as Depends or Recommends.

We just got bug 744447 complaining about this being a security risk.

There is no security risk. These are discovery modules, not publishing modules.

even discovery modules may create security risk... they process data from outside.
an unwanted upnp discovery code used to crash my instant messager.

also: enforcing avahi-daemon for everybody who wants modern volume control is not okay