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
