[OpenAFS] Re: When to publish security advisories?

[Jason Edgecombe]

On 04/15/2011 04:40 PM, Andrew Deason wrote:
> 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...
> good).
>
>> 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_!"
some managers may disagree with that statement.