Security Policy amendments proposal for advisories

Hi everyone,

it’s been few months that we started to use our new Security Policy and I’d like now to propose two minor amendments for it. The first one is about who can see the Github Security Advisories we create as part of the process, the second is about when we create such advisories in the process.

Proposal 1

So my first proposal concerns which people are able to see the security advisories by default. On Github the default value for this, are the owners of the organization where the advisory is published so for us it’s all the XWiki committers, the full list is available here: https://github.com/orgs/xwiki/people

Now we have the situation where people who are not committer should always be able to see the security advisories before they are published. In general it’s the same people who have access to the security mailing-list. So in order to avoid having to put manually individual access to each people on each draft, I propose to create a dedicated Security Team on Github and to add trusted people who are not committers when they request access. Each security advisory created should then be granted access to this Security Team as part of the process.

Proposal 2

For now mainly @tmortagne and myself created the security advisories but so far we’ve both noticed that we don’t create the advisory when the issue is created but when the issue is fixed. They are different reasons for it, one big reason is that we do fix issues created way before the policy has been published, another one is that it’s easier to write details about an issue once it’s fixed.

So I propose that we amend the process of our Security Policy to only create the advisory when the issue is fixed. So it means putting step 4 after step 6 in https://dev.xwiki.org/xwiki/bin/view/Community/SecurityPolicy/#HWhat2019stheprocesstohandlesecurityissuesforcommitters3F.

For both those proposals I open a vote for 1 week, until next monday the 18th. Here’s my +1 for both proposals.

+1 to both proposals

+1 and document it on https://dev.xwiki.org/xwiki/bin/view/Community/SecurityPolicy/ so that readers know that they can request access and understand how it’ll be granted or refused.

+1

While we’re at it, I think we could also announce the fix on the security list as soon as one branch has it. For example right now we have pushed some security fix on a branch but not on others as we’re waiting for feedback on that branch before merging on the other branches. That feedback will take some time, after that branch is released. So I propose that we don’t wait for all branches to be fixed before announcing it on the security list, even though we cannot make it public at that stage (since we don’t have the fixes for the other branches). And the 3 month embargo will only start once all supported branches have had the fix.

I agree I actually sent an email this morning about a similar case where we don’t have all supported branches released with a security fix. I will try to clarify that in the process to specify to send mails in two cases:

  • when a fix is available on a branch
  • when the end date of the embargo is known (i.e. when all supported branches have been released with the fix)

It can be one mail or several depending how it goes / how many branches we support.

Sure, that’s actually what we did so we could make it explicit.