Mark, you've been handling security issues for years? :) One option could be to commit the fix - with a commit message indicating it's a security fix - in a private repo/branch. Include necessary contributors to test the fix, then as the vuln announcement goes out, merge the fix branch into the public repo (I get that this confuses the standard release process). That said, glancing at the older CloudStack security guidance that I put together[1], I didn't suggest that back then. Can't remember if I was following ASF guidance or if there was some thought behind that...
With my mentor/educator/podcaster hat on, I really like guiding folks to look at commits in OSS projects that mitigate security issues. Besides showing "real world" mitigations of issues, often the fix isn't as simple as one would think and that becomes a great learning experience. When I have time I'll dig through commits to find the mitigation, but it's a lot easier for all if it's clearly called out. Separately - reading the PR I noticed current ASF security guidance mentions not creating Jiras for security issues: We've had the ability to add "security" flags in Jira to allow issues to be non-public until intended release. I know this took a bit of management on infra's side, but it seemed to work well. I'm not sure if that functionality has fallen out of favor, but if not, I tend to lean towards documentation/transparency as the tech allows it. [2] John 1: https://web.archive.org/web/20190416025112/https://cloudstack.apache.org/security.html 2: For Github - folks have been asking for "private" issues for a few years, last time I checked that's still not possible AFAIK. I guess if they did implement that, they could also add support for private branches, which could help this discussion a lot... On Sun, Dec 19, 2021 at 2:41 AM Mark Thomas <[email protected]> wrote: > On 18/12/2021 22:52, Hen wrote: > > I was looking at Andrew's excellent clarifications to the CVE process > > language ( https://github.com/apache/www-site/pull/109 ), and one out of > > scope thought I had was to add a couple of steps/substeps. > > > > Currently it says: > > > > "The project team commits the fix. Do not make any reference that > the > > commit relates to a security vulnerability." > > > > I was wondering on stretching that out into the larger text of: > > > > "The project creates a plan for committing the fix and reviews this > > with the Security Team. Once approved, the project team commits the fix. > > This commit will not make any reference that the commit relates to a > > security vulnerability." > > I think this has hit the nail on the head regarding a key problem: How > to educate project teams about the difficulties of navigating that fine > line between having to to commit the fix to a public repository without > giving away the fact that the commit is addressing a security > vulnerability. > > I don't think there is a one size fits all solution to this. Some > projects have been doing this successfully for years (decades even for > some) and we don't want to add overhead to those projects. > > At the other end of the spectrum there are projects that have never > received a vulnerability report before. When a project's processes are > set up to do things in public, it is all too easy for information to > accidentally leak via a public bug report, PR or similar created in > response to a security issue. > > I don't have a good solution for this. > > In outline, the solution is almost certainly more input from those with > experience of handling security issues. It is the detail of how to do > that I don't have. Whether those with the necessary experience are > willing and able to volunteer the time required is a separate > question/problem. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: > [email protected] > >
