[OpenAFS] Re: When to publish security advisories?

Andrew Deason adeason@sinenomine.net
Fri, 15 Apr 2011 15:40:49 -0500

On Fri, 15 Apr 2011 18:53:08 +0100
Simon Wilkinson <sxw@inf.ed.ac.uk> wrote:

> Making security releases is expensive and time consuming - it removes
> developer effort from all of the other things that we want to get
> done, and delays the arrival of releases that actually contain new
> code.

Releases yes, but _advisories_, much less so, as far as I know.

I would vote for doing security advisories on these issues but not
releases. Though, I myself haven't been treating kernel issues as
sensitive issues, but frankly that's because I feel like I'm going to
get ignored if I do so. A clearer statement of intent on where the line
is drawn would help (which this thread will hopefully accomplish, so...

> My supplemental question, is just how much use the "security releases"
> actually are. Most of our packagers ignore them, in favour of pulling
> the patches that we release with the advisory into their packaging. Is
> just providing these patches sufficient? Is there actually a demand
> for a "super-stable" point update that just contains the security
> code, or is it acceptable to provide the security fix as part of a
> normal stable release?

I would agree that the point releases are not useful for issues like
this. For Linux, you're generally getting the module from a distribution
packager (or you have a team to build your own and keep track of patches
etc), and for commercial Unices you usually either have support from
someone that can give you binaries or you know enough to make them
yourself. If you want a "super stable release" you are generally paying
enough attention for one of those options to be viable.

I still think the security advisory in such a scenario is useful,
though. Just me speaking as me, I find it helpful to have something like
that to point at when I'm trying to discuss with someone what code they
want to run.

It may result in many more security advisories, but hey, that's reality.
Not every security advisory is "you must upgrade to fix this _now_!"

Andrew Deason