Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] [Bug 337006] [Security] Disclosure
Product/Component: Community / Architecture Council

Wayne Beaton <wayne@xxxxxxxxxxx> changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #16 from Wayne Beaton <wayne@xxxxxxxxxxx> 2011-05-25 16:39:30 EDT ---
(In reply to comment #14)

By "done" in my previous comment, I mean the part where we display the target

> Three months seems a bit arbitrary, but I see the policy leaves wiggle room for
> individual PMCs to decide what is appropriate. Generally I think disclosure
> should happen when a *release* is available containing the fix - requiring the
> consumer community to take unreleased (un-IP-reviewed, possibly untested)
> software can be harsh in some cases.

I can live with this. Mostly. I can make it part of the release process to
identify the "committer-only" bugs resolved in the release.

I still think we need to deal with longevity. There are a lot of folks who seem
to think that security vulnerabilities should remain closed forever. What do we
do about bugs that aren't fixed in a release, or are never fixed?

I believe that expert wisdom suggests that even security vulnerabilities
without fixes should be disclosed so that consumers can prepare themselves to
mitigate risk.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Back to the top