On Fri, 15 Apr 2011 18:53:08 +0100 Simon Wilkinson <[email protected]> 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_!" -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
