Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

FOMS 2009 CFP

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/foms-2009.html

And here’s a another
conference CFP, this time for Foundations of Open Media
Software 2009 (FOMS). It’s simply the best conference about multimedia on
free systems. Period.

It’s the third iteration now, and the first two were
plain awesome, so don’t miss this one. It happens in Hobart, Tasmania, next to linux.conf.au 2009.

FOMS Logo

Send in your paper! Attend! Spread the word!

Linux Plumbers Conference CFP

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/plumbersconf.html

The Call for Papers for
the Linux Plumbers Conference
in September in Portland is out now. It’s a conference about the core
infrastructure of Linux systems: the part of the system where userspace and the
kernel interface. It’s the first conference where the focus is specifically on
getting together the kernel people who work on the userspace interfaces and the
userspace people who have to deal with kernel interfaces. It’s supposed to be a
place where all the people doing infrastructure work sit down and talk, so that
each other understands better what the requirements and needs of the other are,
and where we can work towards fixing the major problems we currently have with
our lower-level APIs.

I am running the Audio microconf of the Plumbers Conference. Audio
infrastructure on Linux is still heavily fragmented. Pro, desktop and embedded worlds are
almost completely seperate worlds. While we have quite good driver support the
user experience is far from perfect, mostly due because our infrastructure is
so balkanized. Join us at the Plumbers Conference and help to fix this! If you are doing audio infrastructure work on Linux, make sure to attend or — even better — submit a paper!

Sign up soon! Send in your paper early! The conference is expected to sell out pretty quickly!

Plumbers Logo

See you in Portland!

How to convert a GIT SVN mirror into GIT upstream

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/git-mirror-to-upstream.html

Yesterday I did the final steps to convert all my SVN repositories to GIT (including Avahi and PulseAudio). I had been running hot GIT mirrors of the SVN repositories for quite a while now. The last step was the switch to make them canonical upstream, and to disable the SVN repos.

For future Google reference, here are the steps that are necessary to make an SVN GIT mirror into a proper GIT repo:

# On the client:
$ git clone ssh://..../git/foobar foobar
$ cd foobar
$ git checkout trunk
$ git branch -m master
$ git push origin master
# This is a good time to edit the HEAD file on the server and replace its contents "ref: refs/heads/trunk" by "ref: refs/heads/master"
$ git push origin :trunk

This will basically replace ‘trunk‘ by ‘master‘, and make it
the default when clients clone the repository. This will however not rename
tags from the git-svn style to the GIT style. (Which I personally
think would be a bad idea anyway, BTW)

Removing the origin from the server’s config file is a good idea, too, since the repo is now canonical upstream.

Of course, afterwards you still need to create proper .gitignore
files for the repositories. Just taking the value of the old
svn:ignore property is a bad idea BTW, because .gitignore
lists patterns that are used for the directory it is placed in and
everything beneath, while svn:ignore is not applied
recursively.

And finally you need to remove all those $Id$ lines and suchlike
from all source files since they are kind of pointless on GIT. It is left as an
excercise to the user to craft a good sed or perl script to do this
automatically and recursively for an entire tree.

Lazyweb, do you have a good idea how to integrate mutt and
git-am best? I want a key in mutt I can press which will ask me for a
GIT directory and then call git-am --interactive for the currently
selected email. Anyone got a good idea? Right now I am piping the mail from
mutt to git-am. But that sucks, because --interactive refuses to work called like that
and because I cannot specify the git repo to apply this to.

K lovers and event sounds

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/k-lovers-and-event-sounds.html

OK, before more people complain that I didn’t keep the KDE in the loop about
all that
fancy event sound infrastructure work. The complaint is only partially
valid: stuff like the sound specs have been seen before by the KDE guys. And
for the rest it’s just better to have something concrete to discuss about first instead of
just starting an unfocussed discussion about all the grand plans we might have without
ever having looked into actually implementing them.

Shortly after I posted that last blog story of mine I informed
the KDE guys about this, and asked for their comments and suggestions. And
this is
my summary of those dicussions.

A Sixfold Announcement

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/sixfold-announcement.html

Let’s have a small poll here: what is the most annoying feature of a modern
GNOME desktop? You got three options to choose from:

  1. Event sounds, if they are enabled
  2. Event sounds, if they are enabled
  3. Event sounds, if they are enabled

Difficult choice, right?

In my pursuit to make this choice a little bit less difficult, I’d like to draw your attention to the following six announcements:

Announcement Number One: The XDG Sound Theming Specification

Following closely the mechanisms of the XDG
Icon Theme Specification I may now announce you the XDG Sound Theme
Specification which will hopefully be established as the future standard
for better event sound theming for free desktops. This project was started by
Patryk Zawadzki and is now maintained by Marc-André Lureau.

Announcement Number Two: The XDG Sound Naming Specification

If we have a Sound Theming Specification, then we also need an XDG Sound Naming
Specification, again drawing heavily from the original XDG
Icon Naming Specification. It’s based on some older Bango work
(which seems to be a defunct project these days), and is also maintained by
Monsieur Lureau. The list of defined sounds is hopefully much more complete
than any previous work in this area for free desktops.

Announcement Number Three: The freedesktop Sound Theme

Of course, what would the mentioned two standards be worth if there wasn’t a
single implementation of them? So here I may now announce you the first
(rubbish) version of the XDG freedesktop
Sound Theme.. It’s basically just a tarball with a number of symlinks
linking to the old gnome-audio event sounds. It’s only a very small
subset of the entire list of XDG sound names. My hope is that this initial
release will spark community contributions for a better, higher quality default
sound theme for free desktops. If you are some kind of musician or audio
technician I am happy to take your submissions!

Announcement Number Four: The libcanberra Event Sound API

Ok, we now have those two specs, and an example theme, what else is missing
to make this stuff a success? Absolutely right, an actual implementation of the
sound theming logic! And this is what libcanberra is.
It is a very small and lean implementation of the specification. However, it is
also very powerful, and can be used in a much more elaborate way than previous
APIs. It’s all about the central function called ca_context_play()
which takes a NULL terminated list of string properties for the sound you want
to generate. How this looks like?

{
	ca_context *c = NULL;

	/* Create a context for the event sounds for your application */
	ca_context_create(&c);

	/* Set a few application-global properties */
	ca_context_change_props(c,
	                        CA_PROP_APPLICATION_NAME, "An example",
				CA_PROP_APPLICATION_ID, "org.freedesktop.libcanberra.Test",
				CA_PROP_APPLICATION_ICON_NAME, "libcanberra-test",
			        NULL);

	/* ... */

	/* Trigger an event sound */
	ca_context_play(c, 0,
			CA_PROP_EVENT_ID, "button-pressed", /* The XDG sound name */
			CA_PROP_MEDIA_NAME, "The user pressed the button foobar",
			CA_PROP_EVENT_MOUSE_X, "555",
			CA_PROP_EVENT_MOUSE_Y, "666",
			CA_PROP_WINDOW_NAME, "Foobar Dialog",
			CA_PROP_WINDOW_ICON_NAME, "libcanberra-test-foobar-dialog",
			CA_PROP_WINDOW_X11_DISPLAY, ":0",
			CA_PROP_WINDOW_X11_XID, "4711",
			NULL);

	/* ... */

	ca_context_destroy(&c);
}

So, the idea is pretty simple, it’s all built around those sound event
properties. A few you initialize globally for your application, and some you
pass each time you actually want to trigger a sound. The properties listed
above are only a subset of the default ones that are defined. They can be
extended at any time. Why is it good to attach all this information to those
event sounds? First, for a11y reasons, where visual feedback in addition of
audible feedback might be advisable. And then, if the underlying sound system
knows which window triggered the event it can take per-window volumes or other
settings into account. If we know that the sound event was triggered by a mouse
event, then the sound system could position the sound in space: i.e. if you
click a button on the left side of the screen, the event sound will come more
out of your left speaker, and if you click on the right, it will be positioned
nearer to the right speaker. The more information the underlying audio system
has about the event sound the fancier ‘earcandy’ it can do to enhance your user
experience with all kinds of audio effects.

The library is thread-safe, brings no dependencies besides OGG Vorbis (and of
course a Libc), and whatever the used backend requires. The library can
support multiple different backends. Either you can compile a single one
directly into the libcanberra.so library, or you can bind them at
runtime via shared objects. Right now, libcanberra supports ALSA, PulseAudio and a null backend. The library is
designed to be portable, however only supports Linux right now. The idea is to
translate the XDG sound names into the sounds that are native the local
platform (i.e. to whatever API Windows or MacOS use natively for sound events).

Besides all that fancy property stuff it also can do implicit on-demand
cacheing of samples in the sound server, cancel currently playing sounds,
notify an application when a sound finished to play and other features.

My hope is that this piece of core desktop technology can be shared by both
GNOME and the KDE world.

Check out the (complete!) documentation!

Download libcanberra 0.1 now!

Read the README now!

Announcement Number Five: The libcanberra-gtk Sound Event Binding for Gtk+

If you compile libcanberra with Gtk+ support (optional), than you’ll get an
additional library libcanberra-gtk which provides a couple of
functions to simplify event sound generation from Gtk+ programs. It will
maintain a global libcanberra context, and provides a few functions that will
automatically fill in quite a few properties for you, so that you don’t have to
fill them in manually. How does that look like? Deadly simple:

{
	/* Trigger an event sound from a GtkWidget, will automaticall fill in CA_PROP_WINDOW_xxx */
	ca_gtk_play_for_widget(GTK_WIDGET(w), 0,
                               CA_PROP_EVENT_ID, "foobar-event",
			       CA_PROP_EVENT_DESCRIPTION, "foobar event happened",
			       NULL);

	/* Alternatively, triggger an event sound from a GdkEvent, will also fill in CA_PROP_EVENT_MOUSE_xxx  */
	ca_gtk_play_for_event(gtk_get_current_event(), 0
                              CA_PROP_EVENT_ID, "waldo-event",
			      CA_PROP_EVENT_DESCRIPTION, "waldo event happened",
			      NULL);
}

Simple? Yes, deadly simple.

Check out the (complete!) documentation!

Announcement Number Five: the libcanberra-gtk-module Gtk+ Module

Okey, the example code for libcanberra-gtk is already very simple. Can we do
it even shorter? Yes!

If you compile libcanberra with Gtk+ support, then you will also get a ne
GtkModule which will automatically hook into all kinds of events inside a Gtk+
program and generate sound events from them. You can have sounds when you press
a button, when you popup a menu or window, or when you select an item from a
list box. It’s all done automatically, no further change in the program is
necessary. It works very similar to the old sound event code in libgnomeui, but
is far less ugly, much more complete, and most importantly, works for all Gtk+
programs, not just those which link against libgnomeui. To activate this feature $GTK_MODULES=libcanberra-gtk-module must be set. So, just for completeness sake, here’s how the example code for using this feature in your program looks like:

{
}

Yes, indeed. No code changes necessary. You get all those fancy UI sounds for free. Awesome? Awesome!

Of course, if you use custom widgets, or need more than just the simplest
audio feedback for input you should link against libcanberra-gtk yourself, and add
ca_gtk_play_for_widget() and ca_gtk_play_for_event() calls to
your code, at the right places.

Announcement Number Six: My GUADEC talk

You want to know more about all this fancy new sound event world order? Then
make sure to attend my
talk at GUADEC 2008 in Istanbul!

Ok, that’t enough announcements for now. If you want to discuss or
contribute to the two specs, then please join the XDG mailing list.
If you want to contribute to libcanberra, you are invited to join the libcanberra
mailing list.

Of course these six announcements won’t add a happy end to the GNOME sound
event story just like that. We still need better sounds, and better integration
into applications. But just think of how high quality the sound events on e.g.
MacOS X are, and you can see (or hear) what I hope to get for the free desktops
as well. Also my hope is that since we now have a decent localization
infrastructure for our sounds in place, we can make speech sound events more
popular, and thus sound events much more useful. i.e. have a nice girl’s voice telling you “You disc finished
burning!” instead of some annoying nobody-knows-what-it-means bing sound. I am
one of those who usually have there event sounds disabled all the time. My hope
is that in a few months time I won’t have any reason more to do so.

Singapore, Australia, Hong Kong and Recife

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/photos/sg-au-hk.html

In January/February around FOMS 2008 and linux.conf.au I traveled to Singapore, Hong Kong and Australia,
together with two fellow hackers, Kay and David. It took a while until I found the
time to go through and sort all the photos I made on this trip. But finally I am done, and I am not going
to spare you a few shots.

Singapore  
Singapore  
Singapore  
Singapore  

Singapore  
Singapore  
Singapore  
Singapore  
Singapore  
Singapore  

Singapore  
Singapore  
Singapore  
Singapore  
Singapore  
Singapore  

That was Singapore. The next destination on the trip was Australia, more specifically Great Ocean Road and the Northern Territory.

Australia  
Australia  
Australia  
Australia  
Australia  
Australia  

Australia  
Australia  
Australia  
Australia  
Australia  

Australia  
Australia  
Australia  
Australia  
Australia  
Australia  
Australia  
Australia  

Australia  
Australia  
Australia  
Australia  
Australia  
Australia  
Australia  

And on we went, for Hong Kong.

Hong Kong  
Hong Kong  
Hong Kong  
Hong Kong  

Hong Kong  
Hong Kong  
Hong Kong  

In March I attended the BOSSA Conference in Brazil and visited Recife and Olinda.

Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  

Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  

That’s all for now.

GSoC 2008

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/gsoc-2008.html

I am happy that two GSoC projects got accepted that are related to
projects I maintain:

I’d like to thank the GNOME and BlueZ projects for making these GSoC applications a reality.

Finally, Secure Real-Time on the Desktop

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/cgroups-and-rtwatch.html

Finally, secure real-time scheduling on the Linux desktop can be become a
reality. Linux 2.6.25 gained Real-Time
Group Scheduling, a feature which allows to limit the amount of CPU time
real-time processes and threads may consume.

Traditionally on Linux real-time scheduling was limited to priviliged
processes, because RT processes can lock up the machine if they enter a busy
loop. Scheduling is effectively disabled for them — they can do whatever
they want and are (almost) never preempted by the kernel in what they are doing.
In 2.6.12 RLIMIT_RTPRIO was introduced. It’s a resource limit which opened up
real-time scheduling for normal user processes. However the ability to lock up
the machine for RT processes was not touched by this. When using
/usr/security/limits.conf to raise this limit for specific users
they’d gain the ability to lock up your machine.

Due to this raising this limit is a task that is left to the administrator
on all current distros. Shipping a distro with the limit raised by default is
shipping a distro where local users can easily freeze their machines.

It was always possible to write “watchdog” tools that could supervise RT
processes by running on a higher RT priority and checking the CPU load imposed
by the process on the system. However, to this point it was not possible in
any way that would actually be secure (so that processes cannot escape the
watchdog by forking), that wouldn’t require lots of work in the
watchdog (which is a bad idea since it runs at a very high RT priority, thus
while it doing its stuff it will block the important RT processes from
running), or that wouldn’t be totally ugly.

Real-Time Group Scheduling solves the problem. It is now possible to create
a cgroup
for the processes to supervise. The processes cannot escape the cgroup by
forking. Then, by manipulating the cpu.rt_runtime_us property of the
cgroup a certain amount of RT CPU time can be assigned to the cgroup —
processes in the group cannot spend more time than this limit per one
period of time. (The period length can be controlled globally via
/proc/sys/kernel/sched_rt_period_us).

To demonstrate this I wrote a tool rtwatch
which implements this technique in a watchdog tool that is SUID root, creates a
cgroup, and forks off a user defined process inside, it with raised
RLIMIT_PTPRIO but normal user priviliges. The child process can then acquire RT
scheduling but never consume more CPU than allowed by the cgroup, with no
option to lock up the machine anymore.

How to use this?

$ rtwatch 5 rtcpuhogger

This will start the process rtcpuhogger and grant it 5% of the
available CPU time. To make sure that this is not misused by the user rtwatch
will refuse to assign more than 50% CPU time to a single child. Since RT
scheduling is all about determinism it is not possible to assign more than 100%
CPU time (globally in sum) to all RT processes this way. Also, rtwatch will
always make sure that 5% will be left for other tasks.

To work, rtwatch needs to run on Linux 2.6.25 with CONFIG_RT_GROUP_SCHED
enabled. Unfortunately the Fedora kernel is not compiled this way, yet.

Why is all this so great? Those who attended my talk Practical
Real-Time Programming in Userspace at Linux.conf.au 2008 (or watched the
video) will know that besides the fact that I’d love to enable RT support
for PulseAudio in Fedora in coming releases by default I’d also love to
see RT programming more often used in desktop applications. Everywhere were the
CPU time spent on a specific process should not depend on the overall system
load, but solely on the time constraints of the job itself and what is process
needs RT scheduling should be enabled. Examples for this are music or movie
playback (the movie player should have enough time to decode one frame every
25th of a second, regardless what else is running on the system), fancy
animations, quick reactions to user actions (i.e. updating the mouse cursor).
All this for a machine that is snappier and more responsive with shorter
latencies, regardless what else happens on the machine.

The day before yesterday, when Linux 2.6.25 was released, we came a big step closer to
this goal.

Respect $LC_MESSAGES!

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/LC_MESSAGES.html

<rant>

I really dislike if software ignores my setting of $LC_MESSAGES=C and shows
me its UI in German, just because I set $LANG=de_DE. I hate that. I don’t want
no UI strings in German, the translations are mediocre. I want everything else
in German (paper sizes, …), but no strings please. That’s why I configured
my locale settings this way. I don’t want those settings ignored.

Please, developers, read through locale(7) and related man pages before you hack up i18n support. Thank you.

The offenders that pissed me off right now are Firefox and Fedora’s man.

</rant>

The GPL is a Tool to Encourage Freedom, Not an End in Itself

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/04/10/gpl-not-end-in-itself.html

I was amazed to be involved in yet another discussion recently
regarding the old debate about the scope of the GPL under copyright law.
The debate itself isn’t amazing — these debates have happened
somewhere every six months, almost on cue, since around 1994 or so.
What amazed me this time is that some people in the debate believed that
the GPL proponents intend to sneakily pursue an increased scope for
copyright law. Those who think that have completely misunderstood the
fundamental idea behind the GPL.

I’m disturbed by the notion that some believe the goal of the GPL is to
expand copyrightability and the inclusiveness of derivative works. It
seems that so many forget (or maybe they never even knew) that copyleft
was invented to hack copyright — to turn its typical applications
to software inside out. The state of affairs that software is
controlled by draconian copyright rules is a lamentable reality;
copyleft is merely a tool that diffuses the proprietary copyright
weaponry.

But, if it were possible to really consider reduction in copyright
control over software, then I don’t know of a single GPL proponent who
wouldn’t want to bilaterally reduce copyright’s scope for software. For
example, I’ve often proposed, since around 2001, that perhaps copyright
for software should only last three years, non-renewable, and that it
require all who wished to distribute non-public-domain software to
register the source with the Copyright Office. At the end of the three
years, the Copyright Office would automatically publish that now
public-domain source to the world.

If my hypothetical system were the actual (and only) legal regime for
software, and were equally applied to all software — from the
fully Free to the most proprietary — I’d have no sadness at all
that opportunities for GPL enforcement ended after three years, and that
all GPL’d software fell into the public domain on that tight schedule,
because proprietary software and FLOSS would have the same treatment.
Meanwhile, great benefit would be gained for the freedom of all software
users. In short, GPL is not an end in itself, and I wouldn’t want to
ignore the actual goal — more freedom for software users —
merely to strengthen one tool in that battle.

In one of my favorite films, Kevin Smith’s Dogma, Chris
Rock’s character, Rufus, argues that it’s better to have ideas than
beliefs, because ideas can change when the situation does, but beliefs
become ingrained and are harder to shake. I’m not a belief-less person,
but I certainly hold the GPL and the notion of copyleft firmly in the
“idea” camp, not the “belief” one. It’s
unfortunate that the entrenched interests outside of software are (more
or less) inadvertently strengthening software copyright, too. Thus, in
the meantime, we must hold steadfast to the GPL going as far as is
legally permitted under this ridiculously expansive copyright system we
have. But, should a real policy dialogue open on the reduction software
copyright’s scope, GPL proponents will be the first in line to encourage
such bilateral reduction.

The GPL is a Tool to Encourage Freedom, Not an End in Itself

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/04/10/gpl-not-end-in-itself.html

I was amazed to be involved in yet another discussion recently
regarding the old debate about the scope of the GPL under copyright law.
The debate itself isn’t amazing — these debates have happened
somewhere every six months, almost on cue, since around 1994 or so.
What amazed me this time is that some people in the debate believed that
the GPL proponents intend to sneakily pursue an increased scope for
copyright law. Those who think that have completely misunderstood the
fundamental idea behind the GPL.

I’m disturbed by the notion that some believe the goal of the GPL is to
expand copyrightability and the inclusiveness of derivative works. It
seems that so many forget (or maybe they never even knew) that copyleft
was invented to hack copyright — to turn its typical applications
to software inside out. The state of affairs that software is
controlled by draconian copyright rules is a lamentable reality;
copyleft is merely a tool that diffuses the proprietary copyright
weaponry.

But, if it were possible to really consider reduction in copyright
control over software, then I don’t know of a single GPL proponent who
wouldn’t want to bilaterally reduce copyright’s scope for software. For
example, I’ve often proposed, since around 2001, that perhaps copyright
for software should only last three years, non-renewable, and that it
require all who wished to distribute non-public-domain software to
register the source with the Copyright Office. At the end of the three
years, the Copyright Office would automatically publish that now
public-domain source to the world.

If my hypothetical system were the actual (and only) legal regime for
software, and were equally applied to all software — from the
fully Free to the most proprietary — I’d have no sadness at all
that opportunities for GPL enforcement ended after three years, and that
all GPL’d software fell into the public domain on that tight schedule,
because proprietary software and FLOSS would have the same treatment.
Meanwhile, great benefit would be gained for the freedom of all software
users. In short, GPL is not an end in itself, and I wouldn’t want to
ignore the actual goal — more freedom for software users —
merely to strengthen one tool in that battle.

In one of my favorite films, Kevin Smith’s Dogma, Chris
Rock’s character, Rufus, argues that it’s better to have ideas than
beliefs, because ideas can change when the situation does, but beliefs
become ingrained and are harder to shake. I’m not a belief-less person,
but I certainly hold the GPL and the notion of copyleft firmly in the
“idea” camp, not the “belief” one. It’s
unfortunate that the entrenched interests outside of software are (more
or less) inadvertently strengthening software copyright, too. Thus, in
the meantime, we must hold steadfast to the GPL going as far as is
legally permitted under this ridiculously expansive copyright system we
have. But, should a real policy dialogue open on the reduction software
copyright’s scope, GPL proponents will be the first in line to encourage
such bilateral reduction.

The collective thoughts of the interwebz