Small amendments for the security policy process

Development
1

Hello everyone,

I’m opening this proposal for including some small changes in our security policy process.

Reference commits in advisories

This first change is a request we had recently: apparently it’s a common practice to reference the actual commit fixing a security vulnerability in the advisories.
So I propose we start doing the same in our own advisories.

Always provide a reproduction scenario for vulnerability

In order to help the sponsoring company assessing the presence or not of a vulnerability, it’s really helpful to provide a scenario showing the exploit of the vulnerability, or at least describing an oracle to assess the presence of the vulnerability.
Ideally this should be posted directly in the description of the JIRA ticket, either when creating it or when someone starts investigating it for fixing it.

2

+1

Should all commits be mentioned in the advisory or only those on the master branch? This might be particularly relevant when the changes aren’t identical.

3

IMO it’s pretty rare to have a really different fix in two different supported branches. So I’d leave it to the committer opinion to chose to reference all commits if they feel the need. Here I just want to ensure we agree on referencing the master commit.

4

I think it makes sense to reference all commits related to the fix. Even on master, there could be several commits.

5

+1

I understood the proposal as we should list all commits on master branch, but it’s true that @surli mention “commit” without a s.

6

Yes that’s it, I just forgot the plural.

7

I added the information in https://dev.xwiki.org/xwiki/bin/view/Community/SecurityPolicy/#HWhat2019stheprocesstohandlesecurityissuesforcommitters3F.