[gst-devel] Security audit strategy

[Christian Schaller]

After my suggestion of using GStreamer in GNOME 2.0, the request for a
GStreamer security audit has been made by amongst others Alan Cox and
Martin Baulig.

What exactly this security audit should do is more loosly defined, but I
think it is clear that at this time in GStreamer development doing a
security audit will be highly counterproductive. Doing a security audit
would probably be more corect to give priority after we have moved to
glib 2.0 and our core have stabilised. 

But in the meantime I think we need something to reasure the GNOME
hackers, so I propose making
a document outlining our security strategy and auditing plans. Since I
never suggest anything without volunteering myself <grin> I plan on
making a draft of such a document for us. 

But to outline my ideas (and get some early feedback):

We add this document (or a similar one) to out developer documentation.
Having developers aware of
these issues would probably be a good first step.

http://www.dwheeler.com/secure-programs

We make a shortlist of what kind of security risks we should focus on,
for instance buffer overflows and outline a strategy to have a good
security profile in those areas. For instance say that we don't ship a
stable release of GStreamer as long as we know of any media files able
to crash it.

We outline what kind of help/demands we have from commercial backers.
For instance what are RidgeRuns strategy/policy for this. As a part of
GNOME 2.0 can we get help with these issues from Sun QA and/or Linux
distributors?

Once we have such a document we are pleased with we send it of to
gnome-hackers as proof of our commitment to these issues. That way this
is resolved both as in regard to inclusion in GNOME 2.0, but without
valuable development time having to be spent at this point in time.

Christian