Hi, One of the issues that comes up from time to time is what actually constitutes a bug worthy of a security advisory. Sometimes this is really clear cut, but in other areas, in particular in relation to our Unix kernel modules, the dividing line is significantly less clear. Getting this right is important. On one hand, we have an obligation to make people aware quickly when there is an issue that affects the security of their systems. On the other hand, when a change addresses a security issue we have historically made a release containing just that change. 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.
The problem is that any programming mistake in our kernel module will generally result either in the machine locking up, or in the AFS filesystem becoming unusable. We generally find out about these mistakes because a local user triggers them, so from a security point of view, virtually all of them are a local denial of service attack. My proposal, going forwards, is to not produce security advisories or releases for these local denial of service attacks. Local issues that can result in privilege escalation, or denial of service attacks that can be performed by those outside a sites infrastructure would still result in advisories. 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'd welcome feedback about both of these. Cheers, Simon. (with his OpenAFS Security hat on)_______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
