On 11-06-22 04:32 PM, Curtis Hovey wrote: > On Wed, 2011-06-22 at 15:09 -0400, Francis J. Lacoste wrote: >> Thanks for this thorough analysis. One thing that I'm not clear on: >> with >> your new rules, are we dropping the support for public security bug? >> (A >> bug marked as a security vulnerability but is not private?) >> >> Or would they just become "public bug" as part of your rules? > > A public security bug? hmm In my rules it is effectively security, not > public, so only the security role can access it. > > Are you talking about the case of after a security bug is fixed? I had > not considered that. We could say private + security is required to make > the bug visible to only the security team. This works without a schema > change, but it effectively make the two bools act as a 3 state enum. > >
It's called "Full disclosure". Like Kees pointed out, "most security bugs are public, some aren't". These public ones will have been reported in "full disclosure" lists. It's only when a new vulnerability is found (and the finder doesn't endorse full disclosure up front) that the security bug will be private. -- Francis J. Lacoste francis.laco...@canonical.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
