[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse.org-architecture-council] [Bug 337006] [Security] Disclosure

https://bugs.eclipse.org/bugs/show_bug.cgi?id=337006
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
milestone.

> 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.

http://www.schneier.com/essay-146.html

-- 
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.