[pulseaudio-discuss] Example using async API

[Nix]

On 12 Oct 2009, Lennart Poettering told this:

> On Fri, 09.10.09 23:14, Nix (nix at esperi.org.uk) wrote:
>> So... it might be a good idea simply to have a pulseaudio-security
>> mailing list or even blog or something to which you post the git commit
>> IDs of known security fixes (or whatever it is you tell the
>> distributors: I presume it's something like that). ##
>
> Sure. I can do  a lot of things. But how about *you* do these things?
> I announce those things on IRC, so you are welcome to hang around
> there and forward it to some blog.

That requires me to be permanently present on IRC. I'm stuck commuting
and have to sleep so this is impractical.

> The current system works quite well I'd say -- for the distros. You

for the distros *you choose to communicate with*, and we don't even know
who they are: it may even be a matter of whim. Everyone else is screwed.

> think there's more than distros that matters. I don't. So why should I
> do the additional work and you don't?

One Cc:? 'Additional work'? I'm sorry, I assumed that running a
very-low-volume one-posting-subscriber mailing list was essentially no
work if you were already running several higher-volume ones. I didn't
realise it was immensely difficult.

> Also, Colin maintains a -stable branch, which also includes the
> security fixes -- not sure what more you need?

Aha. I didn't notice that these were still active: indeed the recent
security fix doesn't seem to have gone into the older one. I guess this
means that what I'm hoping for *is* there... except that it's not
publicised anywhere.

(More to the point, new security-related commits there are not
advertised anywhere: but I'm happy to set up a robot that advertises
it if you don't mind.)

>> One extra Cc: on emails you already send and everyone is happy.
>
> Uh? It's all on the ML or on IRC. There's nothing private here.

Aha. From your phrasing I thouht it was being sent *only* to
distributors, not to distributors and this list. (I can't recall any
security-related announcements ever being made to this list. Certainly
the patching of the recent actively-exploited PA hole wasn't announced
here.)

>> (the kernel already does something like this with the -stable tree.
>> udev doesn't do anything like this and I bloody wish it did: it tends to
>> intermingle major rules-breaking config changes and critical security
>> fixes in releases, and keeps security fixes quiet. That's *exactly* the
>> wrong thing to do... but you know that.)
>
> Dude, nothing hinders you to maintain your own udev-stable
> tree. 

This is the biggest problem in the free software world, really:
responding to criticisms of major flaws with utterly trivial fixes with
'oh, you do that then'. Adding one email address to a Cc: to help all
users of your software avoid security problems is not rocket science and
takes zero effort as far as I can see, but you responded like I was
suggesting you paint the ceiling of the Sistine Chapel, with proposed
fixes which involved *insane* amounts of effort (24x7 presence on an IRC
channel come-what-may and scanning all the traffic on that channel to
spot a non-automatically-detectable notice which might come up once in
six months, if that? Come on!)

If you really think that upstream PA is only usable by distributors,
that's fine: everyone else should for security's sake drop it and
encourage every program that currently uses it to drop support for it as
well (otherwise they are opening all their users who do not use your
preferred distros to potential security threats).

A shame. It's fine software, better than any other desktop sound system
I've ever used, but it seems it's not safe to use unless I'm in the
right club or have infinite amounts of free time to use to follow
everything you do in micrometric detail.