http://old.nabble.com/PulseAudio-in--extra--td30214159.html
PulseAudio in [extra]
by Jan Steffens-2 Nov 14, 2010; 09:11pm :
I would like to propose moving support for the PulseAudio sound server into
Arch Linux proper. This would also be in preparation for the eventual arrival of
Gnome 3, since it will be unlikely we can effectively maintain the needed
GStreamer patch any more.
To that effect I have created a plan:
---
To provide PulseAudio in [extra]...
Move the following packages from [community] to [extra]:
- libasyncns
- rtkit
- pulseaudio (split into pulseaudio and libpulse)
- alsa-plugins
- pulseaudio-alsa
Configuration package, contains /etc/asound.conf
depends on pulseaudio, alsa-plugins
- pavucontrol
- paprefs
- pulseaudio-mixer-applet
- ossp
provides osspd OSS emulator
Rebuild the following packages with PulseAudio support:
- sdl (sdl-pulse in AUR)
- openal (openal-pulse in AUR)
- libgstreamer0.10-good
split gstreamer0.10-pulse (in community)
- libao
split libao-pulse (in community)
- libcanberra
split libcanberra-pulse (in community)
will be a split plugin instead of a wholly rebuilt copy
- gnome-media
split gnome-media-pulse (in community; rebuilt with --enable-pulse)
- gnome-settings-daemon
split gnome-settings-daemon-pulse (in community; rebuilt without
gstreamer patch)
Provide the following groups:
- pulseaudio-gnome
pulseaudio-alsa
libcanberra-pulse
gstreamer0.10-pulse
gnome-media-pulse
gnome-settings-daemon-pulse
---
One of the problems of PulseAudio is that it pretty much becomes the default as
soon as you install it:
- The client library will start the server if it's not running.
- pulseaudio will install .desktop files that autostart the server together
with Gnome or KDE.
Splitting libpulse would prevent that, but I believe we still need to test
on a per-application basis whether we can enable PulseAudio support (with a
dependency on libpulse) without breaking fallback to ALSA on systems without
pulseaudio.
Some packages (like sdl and openal) look for libpulse dynamically and will
still work even though the lib is missing, so they only need an optional
dependency.
I would be maintaining split -pulse packages where needed.
http://old.nabble.com/Re:-PulseAudio-in--extra--p30222200.html
by Ionuț Bîru-2 Nov 15, 2010; 08:12pm
like Jan pointed out, it would be a paint in the ass to maintain
unsupported patch that is adding support back for gstreamer(like we do
now and is not the arch way)
Jan Steffens has also another "pain in the ass". He compiled VLC player for Arch with PulseAudio http://www.archlinux.org/packages/extra/i686/vlc/
As a result, his VLC player does not play any DVDs (encrypted, or not-encrypted). This is exactly what "The Arch Way" means in this particular case.
NOTE: It turned out that DVD playback with VLC now depends on hardware. On one computer it works invariably (before upgrade and after), on another computer with the same software installed (except for hardware related things) and configured in the same way, you need to recompile VLC to enable playback of DVDs and MPEGs.
If "The Arch Way" is painful for the ass, it might be much more painful with PulseAudio.
To patch "gnome-settings-daemon", one may need a minimal knowledge in programming and some minimal knowledge in Linux. Taking into account the "pain in the ass" caused by VLC, one may imagine how painful "The Arch Way" might be with Gnome 3.
The patches for "gnome-settings-daemon" are still available (in the Attachment). One may open those patches with MELD http://meld.sourceforge.net/ and see that nothing special is inside. If they cannot make such patches, they would not be able to fix VLC, Audacity and many other multimedia applications. This actually means that multimedia applications may fail to work on Arch Linux in the near future.
EDIT: It makes sense to recompile (and rename) all the infected packages:
- Code: Select all
sdl
openal
gstreamer0.10-good
libao
libcanberra
gnome-media
gnome-settings-daemon
fluidsynth
mpd
mplayer
mplayer-vaapi
phonon
and so on.
"libpulse" should be removed. Otherwise, infection will spread like malware.
The problem is that many multimedia packages (Mplayer, VLC, SDL, etc.) are designed in such a way that, if you have "libpulse", they would be automatically compiled with PulseAudio. If you compile something from AUR, you may get PulseAudio, if you do not take preventive measures.
It is not difficult to recompile all the infected packages. PKGBUILDs are available.
The package "gstreamer0.10-good" seems to be buggy on Arch Linux. If you have problems with compilation, you may try to add special options to "./configure" like these:
- Code: Select all
--build=i686-pc-linux-gnu \
--host=i686-pc-linux-gnu
When you try to recompile multi-media packages infected with PulseAudio, you may inevitably notice very strange mistakes in PKGBUILDs. For example, "makedepends" does not contain PulseAudio or libpulse, but, nevertheless, "depends" includes libpulse.
- Code: Select all
# $Id: PKGBUILD 35386 2010-12-19 18:07:35Z foutrelis $
# Maintainer: Evangelos Foutras <foutrelis@gmail.com>
# Contributor: Ionut Biru <ibiru@archlinux.org>
# Contributor: Hugo Doria <hugo@archlinux.org>
pkgname=mplayer-vaapi
pkgver=32723
_vaapi_version=20101115
pkgrel=1
pkgdesc="A movie player, compiled with vaapi support"
arch=('i686' 'x86_64')
url="http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/"
license=('GPL')
depends=('libxxf86dga' 'libxxf86vm' 'libmad' 'cdparanoia' 'libxinerama' 'sdl'
'lame' 'libtheora' 'xvidcore' 'libmng' 'libxss' 'libgl' 'smbclient'
'aalib' 'jack' 'libcaca' 'x264' 'faac' 'lirc-utils' 'ttf-dejavu'
'libxvmc' 'enca' 'opencore-amr' 'libdca' 'a52dec' 'schroedinger'
'libvpx' 'libpulse' 'libva')
makedepends=('unzip' 'mesa' 'live-media>=2010.01.13' 'yasm' 'ladspa')
provides=("mplayer=$pkgver")
conflicts=('mplayer')
backup=('etc/mplayer/codecs.conf' 'etc/mplayer/input.conf')
source=(http://pkgbuild.com/~foutrelis/mplayer-$pkgver.tar.xz
http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/mplayer-vaapi-$_vaapi_version.tar.bz2
mplayer.desktop
mplayer.png
patch-fixes.patch)
md5sums=('1a0ece6c19d32281590f35495d7fbe36'
'372ba02746404d3fa2b3aa94657a2efd'
'647b9f4ab5284a7fef3f84f992214e77'
'd00874ccc644b7f43d6ef1c942fcef28'
'cbddc2d8b1140e274a2784bdbb1f9b04')
build() {
cd "$srcdir/mplayer-$pkgver"
# Custom CFLAGS break the mplayer build
unset CFLAGS LDFLAGS
# Update vaapi patches for changes introduced in mplayer
patch -d "$srcdir/mplayer-vaapi-$_vaapi_version" -p1 -i \
"$srcdir/patch-fixes.patch"
for patch in mplayer-{vaapi{,-{gma500-workaround,0.29}},vdpau}; do
patch -Np1 -i "$srcdir/mplayer-vaapi-$_vaapi_version/patches/$patch.patch"
done
./configure --prefix=/usr \
--enable-runtime-cpudetection \
--disable-gui \
--disable-arts \
--disable-liblzo \
--disable-speex \
--disable-openal \
--disable-fribidi \
--disable-libdv \
--disable-musepack \
--disable-esd \
--disable-mga \
--enable-xvmc \
--disable-vdpau \
--enable-vaapi \
--language=all \
--confdir=/etc/mplayer
[ "$CARCH" = "i686" ] && sed 's|-march=i486|-march=i686|g' -i config.mak
make
make -j1 DESTDIR=$pkgdir install
install -Dm644 etc/{codecs.conf,input.conf,example.conf} "$pkgdir/etc/mplayer/"
install -dm755 "$pkgdir/usr/share/mplayer/"
ln -s /usr/share/fonts/TTF/DejaVuSans.ttf "$pkgdir/usr/share/mplayer/subfont.ttf"
rm -rf "$pkgdir/usr/share/mplayer/font"
# Desktop file (FS#14770)
install -Dm644 "$srcdir/mplayer.desktop" "$pkgdir/usr/share/applications/mplayer.desktop"
install -Dm644 "$srcdir/mplayer.png" "$pkgdir/usr/share/pixmaps/mplayer.png"
}
# vim:set ts=2 sw=2 et:
At the first glance, it looks like "libpulse" was merely planted in the dependencies. It may surely enhance your natural inclination to paranoia, if you have it. You may also notice other "obvious mistakes" (in "libcanberra-oss" as well). This may make you even more suspicious about Arch Linux.
It might be stating the obvious, but PulseAudio is fist of all a security problem:
Clever attack exploits fully-patched Linux kernel
'NULL pointer' bug plagues even super max versions
By Dan Goodin • Friday 17 Jul 2009 22:32
...The exploit works only when a security extension knows as SELinux, or Security-Enhanced Linux, is enabled. Conversely, it also works when audio software known as PulseAudio is installed. http://www.theregister.co.uk/2009/07/17 ... l_exploit/
Security-Enhanced Linux (SELinux)... developed by the United States National Security Agency, it was released to the open source development community under the GNU GPL on December 22, 2000 and merged into the mainline kernel 2.6.0-test3, released on 8 August 2003. http://en.wikipedia.org/wiki/Security-Enhanced_Linux
CryptoSystem Backdoors (Security Now! podcast) http://www.grc.com/sn/sn-268.htm
Description: Steve and Leo discuss the deeply troubling recent news of possible legislation that would require all encrypted Internet communications, of any kind, to provide a means for U.S. law enforcement "wiretap" style monitoring.
High quality (64 kbps) mp3 audio file URL: http://media.GRC.com/sn/SN-268.mp3
Quarter size (16 kbps) mp3 audio file URL: http://media.GRC.com/sn/sn-268-lq.mp3
OpenBSD founder Theo de Raadt wrote that a firm was probably contracted to put backdoors in OpenBSD project code, but it is unlikely the flaws made it very far if they existed. http://www.eweek.com/c/a/Security/OpenB ... rs-405542/
FBI 'planted backdoor' in OpenBSD
Posted in Enterprise Security, 15th December 2010 13:12 GMT
Allegations that the FBI may have smuggled back doors or weaknesses into openBSD's cryptography have created uproar in the security community. http://www.theregister.co.uk/2010/12/15 ... oor_claim/
OpenBSD backdoor claims: bugs found during code audit
By Sam Varghese
Friday, 17 December 2010 09:31
The OpenBSD project has found two bugs during an audit of the cryptographic code in which, it has been alleged, the FBI, through former developers, was able to plant backdoors.
OpenBSD project head Theo de Raadt told iTWire: "We've been auditing since the mail came in! We have already found two bugs in our cryptographic code. We are assessing the impact. We are also assessing the 'archeological' aspects of this.." http://www.itwire.com/opinion-and-analy ... dit-begins
OpenBSD Founder Believes FBI Built IPsec Backdoor
By Mathew J. Schwartz , InformationWeek
December 22, 2010 11:45 AM
The OpenBSD project has found two bugs in how OpenBSD, a Unix-like open source operating system, implements Internet protocol security (IPsec).
The bugs are of interest given the recent allegation made by Gregory Perry, former CTO of now-defunct Federal Bureau of Investigation contractor Network Security Technology (NetSec), that the FBI created a backdoor in the OpenBSD code base, specifically in how it implements IPsec. He also alleged that multiple developers involved in contributing code to OpenBSD were on the payroll of NetSec, and that the FBI had hired it to create the backdoors. http://www.informationweek.com/news/sec ... ed_IWK_All
Taking into account that security experts are professional paranoids, you can imagine what kind of "paint in the ass" it might be for Ionuț Bîru, Jan Steffens et al. who planted "libpulse" in multi-media packages for Arch Linux.
It might be much easier to patch "gnome-settings-daemon" (for Gnome 3) than to prove that "backdoors" have not been smuggled into Arch Linux.
Allegations of OpenBSD Backdoors May be True, Updated | Linux Journal
22 Dec 2010 ... It was just last week that Theo de Raadt, OpenBSD founder and developer, posted an email that claimed the Federal Bureau of Investigations ... http://www.linuxjournal.com/content/all ... ay-be-true
OpenBSD chief believes contractor tried to write backdoors | ITworld
22 Dec 2010 ... Discussing allegations, Theo de Raadt says that government contractor Netsec 'was probably contracted to write backdoors'...
...If there is a 10-year-old back door in OpenBSD, it would be hard to identify, as it would probably look just like any other security vulnerability. But it would give anyone who knew about it a way to eavesdrop on supposedly secure Internet communications -- VPN traffic, for example -- that used the buggy software. http://www.itworld.com/operating-system ... -backdoors
An FBI backdoor in OpenBSD?
...at this point, it seems that nobody but Perry really knows what's going on. It's hard to really know what to say at this point. We're talking about backdoors that probably just look like regular old bugs in code that was written 10 years ago. http://blogs.csoonline.com/1296/an_fbi_ ... in_openbsd
To summarize:
A. backdoors are indistinguishable from "regular old bugs" (side channel leakage http://en.wikipedia.org/wiki/Side_channel_attack )
B. the only available information is Perry's letters:
1. Gregory Perry to Theo de Raadt:
http://marc.info/?l=openbsd-tech&m=129236621626462&w=2
2. Gregory Perry to Robert McMillan:
http://blogs.csoonline.com/1296/an_fbi_ ... in_openbsd
The latter was republished by "Full Disclosure":
Full Disclosure: Perry explains OpenBSD backdoor more
http://seclists.org/fulldisclosure/2010/Dec/441
Thus, the only objective fact (available for us) is that certain letters contain really shocking information (which is impossible to verify). All other publications are mere subjective interpretations of somebody's words. There is, however, another fact:
http://www.theregister.co.uk/2007/11/16/random_number_backdoor_fears/
Crypto guru warns over random number backdoor
By John Leyden • 16th November 2007 19:19 GMT
A top cryptographer has expressed concern about a possible backdoor in a standard for random-number generators approved by the National Institute of Standards and Technology (NIST) this year...
Shumow and Ferguson described their finding as a weakness and are at pains to avoid suggestions that NIST intentionally put a back-door in the function. Schneier is less circumspect saying that the "algorithm contains a weakness that can only be described a backdoor".
http://www.theregister.co.uk/2008/08/27/ssh_key_attacks_warning/
CERT: Linux servers under 'Phalanx' attack
By Dan Goodin in San Francisco • 27th August 2008 00:13 GMT
The CERT advisory makes no mention of the flaw in the Debian random number generator, but that's most likely the starting point for the attack.
Does the study of source code make any sense? Imagine that you have a kind of PulseAudio (or other useless thing installed). You may get a backdoor (which may "look just like any other security vulnerability") together with an update, and it might be removed with the next update. Since PulseAudio is fundamentally buggy, a backdoor might be indistinguishable from other bugs. Even if you are able to read and understand the source code, it might be very difficult to detect a backdoor, before your system is pwned. If you are a true paranoid, you have to remove almost all software and study the source code of each update, before it is installed.
libpulse does produce new problems (not to mention PulseAudio)
https://bbs.archlinux.org/viewtopic.php?id=110398
What is more, it seems that libpulse tends to behave like a trojan, or rootkit, and, therefore, you may get warnings from rkhunter, see:
http://forums.techguy.org/linux-unix/88 ... found.html
https://bugs.launchpad.net/ubuntu/+sour ... bug/559545
By planting "libpulse" into Arch Linux, the Arch developers made it clear that the KISS principle is already abandoned, and the Arch Way too https://wiki.archlinux.org/index.php/Be ... e_Arch_Way
All such principles are nothing more than an ideological deception.
Do you remember Ubuntu's "humanism"? http://en.wikipedia.org/wiki/Ubuntu_(philosophy)
