It is a fact that in the last time the security team has a lack of manpower or in other words, the security bugs need more eyes. Please do not complain about that, because this post is not intended to blame, but is here to give some hints for who occasionally touch the bugs.
First of all, for who want to have a complete view, we have a full guide about the Vulnerability Treatment Policy, but here I will summarize what you can do in any cases without security-related knowledge.
Usually, in the last time, the maintainer, after the bump, adds the arch teams in the CC field, which is positive because the process continues, but this is negative because that action is only a part of the needed task.
So, when you are taking care of the addition of the arch teams, please consider these three points:
- The Summary;
- The Whiteboard;
- The Keywords.
In the summary you are able to see:
- the name of the package;
- the name of the issue;
- the CVE identifier.
You don’t need to touch the name of the issue or the CVE identifier but you need only to specify the fixed version of the package; A common example about this:
You are touching a bug which says:
app-misc/foo : Buffer Overflow Vulnerability (CVE-2012-1234)
For you the fixed version to stabilize is the 3.0.1. The summary will be:
<app-misc/foo-3.0.1 : Buffer Overflow Vulnerability (CVE-2012-1234) which means that all versions before the 3.0.1 are vulnerable to this bug. Your work with the summary is finished.
The Whiteboard contains the severity level of the bug and the status. The first should be handled by a security team member, but if you are CC’ing the arches, you can take care of the status that will be stable.
A common example:
You have a Whiteboard which says:
It will be:
If the Whiteboard is completely empty, you can skip the security level and add only the stable status, so for example:
The security team will evaluate the status and change the ?? to [A-C][0-4]
The KEYWORD, obviously is STABLEREQ; don’t forget it or it won’t appear on our saved-searches.