On 1/10/14, 5:38 AM, Jeff Trawick wrote: > [ ] It is an accepted practice (but not required) to obscure or omit the > vulnerability impact in CHANGES or commit log information when committing > fixes > for vulnerabilities to any branch. > > [ ] It is mandatory to provide best available description and any available > tracking information when committing fixes for vulnerabilities to any branch, > delaying committing of the fix if the information shouldn't be provided yet. > > [ ] _______________ (fill in the blank)
The Subversion project has struggled with this same issue. To the degree that there has actually been a fair amount of thought into how to avoid doing security by obscurity. The processes we've discussed have varied from executing the release entirely hidden from anyone but the PMC to simply publishing an advisory with a patch right before committing to trunk (treating that advisory with patch as a release with appropriate voting handled by PMC members privately). You're always dealing with a certain amount of security by obscurity. The bugs we find often have existed for a long time. If one person can find it someone else certainly could. For all we know the issues may have already been found and only exploited in limited ways such that the issue was never reported. Even with advance notification I've found that the binary packagers can take their sweet time getting security fixes included. Some binary packagers don't really have a process that supports patching (they release one package for each version without a method of identify versions that have been patched). Administrators may not always know what to do with patches. So frankly all of the processes stink. Yet, I think that the best process is to reveal security issues when you can put your best foot forward and have things positioned to get the fixes in the hands of as many users as possible as quickly as possible. I think that's best served by withholding details (even if you're doing so imperfectly) until release or the issue is widely disclosed to the public. It should be noted that not all security issues are equal. For the most part highly critical fixes are rare, when they do come up we could use a release process that hides everything from non-PMC members until release time frame. With other less severe issues possibly just disclosing immediately when we apply the fix. There doesn't need to be a one size fits all answer to this. But I certainly would like to see us have a consistent policy for determining which process to follow. So my vote wouldn't really fit into the options presented above. I'd suggest coming up with a process for varying levels of issues and criteria to determine which process to follow.
