[pulseaudio-discuss] Example using async API

[Lennart Poettering]

On Wed, 07.10.09 19:01, Jeremy Visser (jeremy at visser.name) wrote:

> 
> On Tue, 2009-10-06 at 00:37 +0200, Lennart Poettering wrote:
> > If you are a user then you should use tha PA version that is shipped
> > with your distro. If you want a newer version, then upgrade your
> > distro. If you are a developer who writes third party apps then you
> > should stick to a released distro, too. But of course you should
> > really make sure to run the latest one.
> 
> You know as well as I do that not everybody can run the latest
> bleeding-edge distro. The reasons are the same as why you would not
> recommend end-users make everyday use of the git version of Pulse.

A released distro such as F11 is not bleeding-edge. A development
distro such as Rawhide is.

F11 is tested and released, and not at all comparable to a git version
of an upstream project.

For a developer there is really no excuse in running anything but the
latest released distro or current development distro, sorry.

> My main concern is that of security, which is the main scenario where
> you would want to update to a recent version of Pulse in a "stable"
> environment. PulseAudio has not been free of security issues, and yet I
> don't know of any "security-only" releases. (Please correct me if I am
> wrong.)

Security updates is the job of distributions. If we encounter a
security issue I contact the packagers I know and tell them which
patch to backport. It's the job of the distro packagers to then apply
that to their packages and pass it on to the users.

A user should not have to deal with upstream PA, ever. If he had to
deal with every single upstream project to have a secure system he'd
go crazy.

> If a security issue is discovered in Pulse, affecting several of the
> latest versions, and a new version is released to correct the security
> hole (as of the time of writing, that would be 0.9.19.1 or 0.9.20), then
> what should those running stable distros do?

I am sorry, but you are seriously misunderstanding the roles of
distributions. It's the distributor's job to provide you with fixed
packages, not upstream! It is upstream's job to come up with a fix or
bless it, but not to update the packages for you.

> Obviously we can't update system libraries such as udev, BlueZ, etc.
> when we just want the security fix. At the same time, Pulse's current
> attitude towards dependencies means running the latest Pulse on the
> system without upgrading much of the core will be problematic.

Of course you can update udev, BlueZ, etc.! And that happened a couple
of times in the past. 

Just check out the security mailing lists the distros maintain. For
example, this is the one of Fedora:

https://www.redhat.com/archives/fedora-package-announce/

Look for all those mails marked as [SECURITY]. They inform you about
security updates of distro packages.

PA falls under exactly the same category as udev, BlueZ. While it is
run under a normal user id it still is kind of a system-level daemon
that integrates closely with kernel, udev, bluez.

If you do a feature upgrade of PA you hence need to do a full
udev/kernel/bluez update too.

If you do a security upgrade of PA you don't need to upgrade anything
else, since security updates are minimal in nature.

> On Mon, 2009-10-05 at 23:04 +0200, Lennart Poettering wrote:
> > PA is pretty tightly integrated into the system. Consider it part of
> > the the OS itself. So it is only feasible to update the entire OS or
> > nothing at all.
> 
> ...does not address the security implications of not updating, in which
> not updating would lead to compromised systems (e.g. if an Adobe Flash
> animation could exploit PulseAudio by playing the audio of a Vista
> install disc backwards).

A security upgrade is a completely different beast than a feature upgrade.

> Is there a "best practice" or other tip you can give us to prepare for
> these situations in which we really do need to upgrade?

Yes, listen to your distributor. He will provide you with packages if
you are a user. Upstream packages are only interesting for developers
and packagers. 

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4