Changing link filtering

David Cafaro dac at
Thu Nov 12 18:21:24 UTC 2015

On 11/12/2015 12:44 PM, pjp at wrote:
>> On Thursday, 12 November 2015 8:35 PM, David Cafaro <dac at> wrote:
>   It shows a single bug BZ#1209214, right? It appears to be filed by a user
> and then converted into a 'SecurityTracking' bug. Generally 'SecurityTracking'
> bugs are created by automated tools which set both priority and severity to
> be same.[*]

There had been two bugs in there, the other had no priority and no
severity.  I mentioned it in the meeting this morning and Sparks updated
it with priority and severity.

It's good the automated tools do this, but it's good to catch the manual
ones like this as well.

> That have a severity rating of High, were being grouped under the
> Unknown listing, since priority was unspecified.
>   Most likely user missed to set the priority.

Yes, likely problem, but I see it happening again, I'm sure.

>   I think above case is a one off. We need not change the query
> on the FST page, but if we must, we could include both 'priorty'
> and 'severity' field in the query.

The above cases were one-off's but I expect them to happen again.  Not
frequently, but they will happen again.

The main reason I suggest changing our filter is that the Priority is
likely something set according to the view of the developer/team in
regards to how it fits into their overall work backlog.  The Severity is
a rating based how "bad" it is.  From a security perspective we may
think of something as having a higher priority due to certain types of
Severity vs the developers Priority to working on the bug.  Including
them both might be the best way to go.

Due to automation, as you point out, most of the time they will match. 
But for manually reported stuff, which we are also trying to capture,
there may be differences between the two.


More information about the security-team mailing list