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