[ntp:security] Bug states

Harlan Stenn stenn at nwtime.org
Mon Oct 26 02:22:28 UTC 2020


+security at ntp.org

On 10/25/2020 5:16 PM, David Miller wrote:
> If you can trust the reporter to know if it's a security bug when they
> file it, then there is indeed a way to make the bug hidden when a box is
> checked on the form when they file it.  Mozilla uses this.  Unless you
> seem to get a lot of seemingly innocuous bugs file that are later
> determined to be security issues, that's probably the better way to do
> it.  Forcing everything to be pre-screened is best done also with a
> security group, you just have that set by default when bugs are filed
> and allow specific people to be able to remove it.  The setup for both
> tactics is done in Bugzilla's config on a product-by-product basis.
> 
> Trying to make it use a status would require more work and more likely
> to cause places where it gets missed since you'd have to put code in
> every possible path to get to it, whereas with a bug group set on it,
> all the code to hide it is already there.

Makes sense.

The problem as I see it is that while security reports are rare, there
is a VERY rare chance the reported bug is a doozy, and I have seen cases
where even a security reporter has forgotten to check the "this is a
security bug" box.

I'm thinking that even though it will be a PITA, we could have a
restricted-access group for all (?) new bugs, and any member of that
group can triage/vet the reports, and either turn them in to unconfirmed
(security/non-security) or resoslved bugs.

I know that this is going to create some work for the "team" of folks
who will look at these, and we're really going to want to watch this
queue closely.  On the other hand, if a Really Bad One is found and
makes it to the wild, that would be pretty horrible.

I'd appreciate feedback from folks on this one.

H
--
> On 10/24/20 2:40 AM, Harlan Stenn wrote:
>> Dave,
>>
>> Right now, bugs.ntp.org uses a status table that includes:
>>
>> - UNCONFIRMED
>> - CONFIRMED
>> - IN-PROGRESS
>> - STAGED
>> - RESOLVED
>>
>> As you might recall, this has a couple of problems.
>>
>> The first is that, as I understand it, unconfirmed bugs generally either
>> get to be CONFIRMED or RESOLVED{worksforme,whatever}.  The problem is
>> that when somebody reports a bug, we get email telling us to triage the
>> bug and decide if it's a security issue or not.  But if we start
>> exchanging emails as part of the triage process we keep getting the
>> "triage" email on every exchange.  But for non-security bugs there's no
>> reason to keep the bug "hidden".
>>
>> And it's not clear to me that UNCONFIRMED bugs are hidden, which means
>> somebody could report an unconfirmed bug that has not been triaged for
>> whether or not it is a security bug, and it's still visible.  For
>> example, https://bugs.ntp.org/show_bug.cgi?id=3695 which has received
>> comments from David Taylor.
>>
>> This also goes to when we can declare a bug as a security bug.  Right
>> now, that can't be done when we create a bug, and for folks who have
>> CANCOMMIT set, that means their created bugs are instantly visible.
>>
>> So I'm wondering if we need another step in there.
>>
>> Is the following reasonable?  Is there a better way?
>>
>> If we cannot designate a bug as a security bug when we open it, then
>> Everybody who creates a bug creates it in the PRESCREEN state.
>>
>> PRESCREEN bugs should be invisible to anybody who does not have CANCOMMIT.
>>
>> If the "screener" decides the bug might be a security bug, they limit
>> its access.
>>
>> Either then or later, the screener would mark the bug as one of
>> UNCONFIRMED, CONFIRMED, or RESOLVED.
>>
>> If we allow people to create bugs that have the "security bug" flag set
>> in them *and they set it*, it seems reasonable to let those go into the
>> UNCONFIRMED state.
>>
>> Make any sense?  Are there better ways to go?
>>
> 
> 
> 

-- 
Harlan Stenn <stenn at nwtime.org>
http://networktimefoundation.org - be a member!


More information about the security mailing list