policy_2011.php - gerrit/www.eclipse.org/security - Git at Google

 <?php
 /*******************************************************************************
  * Copyright (c) 2011 Eclipse Foundation and others.
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * http://www.eclipse.org/legal/epl-v10.html
 *
 * Contributors:
 *    Wayne Beaton (Eclipse Foundation)- initial API and implementation
 *******************************************************************************/
 require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");
 require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php");
 require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php");
 $App = new App();
 $Nav = new Nav();
 $Menu = new Menu();
 include($App->getProjectCommon());

 $pageTitle 		= "Eclipse Security Policy";
 $pageAuthor		= "";
 $pageKeywords	= "Eclipse, projects, security";

 require_once dirname(__FILE__) . '/../projects/classes/images.inc';

 ob_start();
 ?>
 <div id="maincontent">
 	<div id="midcolumn">
 		<h1><?php echo $pageTitle; ?></h1>
 		<a name="Overview"></a>
 		<h2>Overview</h2>
 		<p>The purpose of the Eclipse Security Policy is to set forth the
 			general principles under which the Eclipse Foundation will manage the
 			reporting, management, discussion, and disclosure of Vulnerabilities
 			discovered in Eclipse software. This Security Policy applies to all
 			software distributed by the Eclipse Foundation, including all
 			software authored by Eclipse Committers and third-parties. This IP
 			Policy should at all times be interpreted in a manner that is
 			consistent with the Purposes of the Eclipse Foundation as set forth
 			in the Eclipse Foundation Bylaws.</p>
 		<p>
 			This document uses terms from the <a
 				href="http://www.eclipse.org/projects/dev_process/development_process.php"
 				class="external text"
 				title="http://www.eclipse.org/projects/dev_process/development_process.php"
 				rel="nofollow">Eclipse Development Process</a>.
 		</p>
 		<a name="Eclipse_Security_Team"></a>
 		<h2>Eclipse Security Team</h2>
 		<p>The Security Team is the first line of defense: it is effectively a
 			triage unit with security expertise. Ultimately, Vulnerabilities are
 			resolved by individual projects with assistance from the Security
 			Team.</p>
 		<p>The Security Team is composed of a small number of security
 			experts. At any point in time, there are no more than seven (7)
 			members, including a minimum of one representative each from the
 			Eclipse and RT Top-Level Projects, and a representative of the
 			EMO(ED). All members are appointed by EMO(ED).</p>
 		<p>Mail sent to the security mail address is sent exclusively to all
 			members of the Security Team. Anybody can send mail to this address.
 		</p>
 		<a name="Reporting"></a>
 		<h2>Reporting</h2>
 		<p>Vulnerabilities can be reported either via email or directly with a
 			project via Bugzilla.</p>
 		<p>The general security mailing list address is security@eclipse.org.
 			Members of the Eclipse Security Team will receive messages sent to
 			this address. This address should be used only for reporting
 			undisclosed Vulnerabilities; regular bug reports and questions
 			unrelated to Vulnerabilities in Eclipse software will be ignored.
 			Note that this email address is not encrypted.</p>
 		<p>The community is encouraged to report Vulnerabilities using the
 			standard Eclipse Bugzilla instance. Bug reports related to
 			Vulnerabilities must be marked as "committers-only", either by the
 			reporter, or by a committer during the triage process.</p>
 		<p>Note that bugs marked "committers-only" are visible to all Eclipse
 			committers. By default, a "committers-only" bug is also accessible to
 			the reporter and individuals explicitly indicated in the "cc" list.
 			These defaults can be overridden to further restrict access at the
 			discretion of the committer and project leadership.</p>
 		<dl>
 			<dd>
 				<i>Note that Bugzilla sends out emails as bugs are modified. Email
 					is inherently insecure.</i>
 			</dd>
 		</dl>
 		<a name="Discussion"></a>
 		<h2>Discussion</h2>
 		<p>Initial discussion of an open Vulnerability may occur privately
 			amongst members of the Security Team. Discussion should be moved to a
 			Bugzilla record in a timely manner.</p>
 		<a name="Resolution"></a>
 		<h2>Resolution</h2>
 		<p>A Vulnerability is considered resolved when either a patch or
 			workaround is available, or it is determined that a fix is not
 			possible or desirable.</p>
 		<p>The Eclipse IP Team will give priority to contribution
 			questionnaires (CQs) required to resolve Vulnerabilities.</p>
 		<p>It is left to the discretion of the Security Team and project
 			leadership to determine what subset of the project committers are
 			best suited to resolve Vulnerabilities. The Security Team and project
 			leaders may also&mdash;at their discretion&mdash;assemble external
 			resources (e.g. subject matter experts) or call on the expertise of
 			the Architecture Council.</p>
 		<a name="Distribution"></a>
 		<h2>Distribution</h2>
 		<p>Once a Vulnerability has been resolved, the updated software must
 			be made available to the community.</p>
 		<p>At a minimum, updated software is made available via normal project
 			distribution channels (e.g. downloads and update sites).</p>
 		<p>The planning council must be made aware of Vulnerabilities in
 			software that is part of the simultaneous release. The Planning
 			Council will determine whether or not a "respin" of the simultaneous
 			release repository and EPP packages is required. The Planning Council
 			will coordinate the timing of the "respin" with the Project
 			Leadership.</p>
 		<a name="Disclosure"></a>
 		<h2>Disclosure</h2>
 		<p>Disclosure is initially limited to the reporter and all Eclipse
 			Committers, but can be expanded to include other individuals.</p>
 		<p>All Vulnerabilities must be disclosed, regardless of the
 			resolution. Users and administrators of Eclipse software must made
 			aware that a vulnerability exists so they can assess risk, and take
 			the appropriate action to protect their users, servers and systems
 			from potential exploit.</p>
 		<a name="Timing"></a>
 		<h3>Timing</h3>
 		<p>The timing of disclosure is left to the discretion of the project
 			leadership, including the Project Lead(s), PMC, and EMO(ED). In the
 			absence of specific guidance from the project leadership, the
 			following guidelines are recommended:</p>
 		<ul>
 			<li>Vulnerabilities for which there is a patch, workaround or fix,
 				should be disclosed to the community immediately.</li>
 			<li>Vulnerabilities&mdash;regardless of state&mdash;must be disclosed to the
 				community after a maximum three months.</li>
 		</ul>
 		<p>Vulnerabilities need not necessarily be resolved at the time of
 			disclosure.</p>
 		<a name="Quiet_Disclosure"></a>
 		<h3>Quiet Disclosure</h3>
 		<p>
 			A Vulnerability can be <i>quietly</i> disclosed by simply removing
 			the 'committers_only' flag. The bug's history will record that the
 			flag has been removed, and the bug will become visible for everyone
 			in searches.
 		</p>
 		<p>In general, quiet disclosure is appropriate only for bugs that are
 			identified by a committer as having been erroneously marked as
 			Vulnerabilities.</p>
 		<a name="Progressive_Disclosure"></a>
 		<h3>Progressive Disclosure</h3>
 		<p>Knowledge of a Vulnerability can be easily extended to individuals
 			by adding them to the "cc" list on the bug. A Vulnerability may--at
 			the discretion of the committer--be disclosed to specific
 			individuals. A committer may, for example, provide access to a
 			subject-matter expert to solicit help or advice. The Vulnerability
 			may also be disclosed to known adopters to allow them an opportunity
 			to mitigate their immediate risk and prepare for a forthcoming
 			resolution.</p>
 		<p>Contacts added to an unresolved Vulnerability must be individuals.
 			Groups (e.g. mailing lists)--with the exception of
 			security@eclipse.org--should never be copied on a Vulnerability bug.
 		</p>
 		<a name="Full_Disclosure"></a>
 		<h3>Full Disclosure</h3>
 		<p>All Vulnerabilities must ultimately be fully disclosed to the
 			community at large.</p>
 		<p>
 			All Vulnerabilities affecting projects that participate in the
 			Simultaneous Release must be reported to the Planning Council prior
 			to full disclosure to the community at large. Disclosure of a
 			Vulnerability must be coordinated with the distribution of the
 			updated software from the Project's own distribution channels, the
 			Simultaneous Release repository, and EPP packages (please see <a
 				href="#Distribution" title="">Distribution</a>.
 		</p>
 		<p>To complete the disclosure of a Vulnerability, the committers-only
 			flag must be removed from the bug and the 'security' keyword added.
 			Bugs in this state are automatically reported on the security page
 			and RSS feed.</p>
 		<a name="Escalation"></a>
 		<h3>Escalation</h3>
 		<p>
 			A security vulnerability may--at the discretion of the project
 			leadership--be escalated to a outside body such as <a
 				href="http://www.cert.org" class="external text"
 				title="http://www.cert.org" rel="nofollow">CERT</a>. The EMO can
 			provide assistance.
 		</p>
 	</div>
 </div>

 <?php
 	$html = ob_get_contents();
 	ob_end_clean();

 	$App->generatePage('Nova', $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
 ?>
	<?php
	/*******************************************************************************
	* Copyright (c) 2011 Eclipse Foundation and others.
	* All rights reserved. This program and the accompanying materials
	* are made available under the terms of the Eclipse Public License v1.0
	* which accompanies this distribution, and is available at
	* http://www.eclipse.org/legal/epl-v10.html
	*
	* Contributors:
	* Wayne Beaton (Eclipse Foundation)- initial API and implementation
	*******************************************************************************/
	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");
	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php");
	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php");
	$App = new App();
	$Nav = new Nav();
	$Menu = new Menu();
	include($App->getProjectCommon());

	$pageTitle = "Eclipse Security Policy";
	$pageAuthor = "";
	$pageKeywords = "Eclipse, projects, security";

	require_once dirname(__FILE__) . '/../projects/classes/images.inc';

	ob_start();
	?>
	<div id="maincontent">
	<div id="midcolumn">
	<h1><?php echo $pageTitle; ?></h1>
	<a name="Overview"></a>
	<h2>Overview</h2>
	<p>The purpose of the Eclipse Security Policy is to set forth the
	general principles under which the Eclipse Foundation will manage the
	reporting, management, discussion, and disclosure of Vulnerabilities
	discovered in Eclipse software. This Security Policy applies to all
	software distributed by the Eclipse Foundation, including all
	software authored by Eclipse Committers and third-parties. This IP
	Policy should at all times be interpreted in a manner that is
	consistent with the Purposes of the Eclipse Foundation as set forth
	in the Eclipse Foundation Bylaws.</p>
	<p>
	This document uses terms from the <a
	href="http://www.eclipse.org/projects/dev_process/development_process.php"
	class="external text"
	title="http://www.eclipse.org/projects/dev_process/development_process.php"
	rel="nofollow">Eclipse Development Process</a>.
	</p>
	<a name="Eclipse_Security_Team"></a>
	<h2>Eclipse Security Team</h2>
	<p>The Security Team is the first line of defense: it is effectively a
	triage unit with security expertise. Ultimately, Vulnerabilities are
	resolved by individual projects with assistance from the Security
	Team.</p>
	<p>The Security Team is composed of a small number of security
	experts. At any point in time, there are no more than seven (7)
	members, including a minimum of one representative each from the
	Eclipse and RT Top-Level Projects, and a representative of the
	EMO(ED). All members are appointed by EMO(ED).</p>
	<p>Mail sent to the security mail address is sent exclusively to all
	members of the Security Team. Anybody can send mail to this address.
	</p>
	<a name="Reporting"></a>
	<h2>Reporting</h2>
	<p>Vulnerabilities can be reported either via email or directly with a
	project via Bugzilla.</p>
	<p>The general security mailing list address is security@eclipse.org.
	Members of the Eclipse Security Team will receive messages sent to
	this address. This address should be used only for reporting
	undisclosed Vulnerabilities; regular bug reports and questions
	unrelated to Vulnerabilities in Eclipse software will be ignored.
	Note that this email address is not encrypted.</p>
	<p>The community is encouraged to report Vulnerabilities using the
	standard Eclipse Bugzilla instance. Bug reports related to
	Vulnerabilities must be marked as "committers-only", either by the
	reporter, or by a committer during the triage process.</p>
	<p>Note that bugs marked "committers-only" are visible to all Eclipse
	committers. By default, a "committers-only" bug is also accessible to
	the reporter and individuals explicitly indicated in the "cc" list.
	These defaults can be overridden to further restrict access at the
	discretion of the committer and project leadership.</p>
	<dl>
	<dd>
	<i>Note that Bugzilla sends out emails as bugs are modified. Email
	is inherently insecure.</i>
	</dd>
	</dl>
	<a name="Discussion"></a>
	<h2>Discussion</h2>
	<p>Initial discussion of an open Vulnerability may occur privately
	amongst members of the Security Team. Discussion should be moved to a
	Bugzilla record in a timely manner.</p>
	<a name="Resolution"></a>
	<h2>Resolution</h2>
	<p>A Vulnerability is considered resolved when either a patch or
	workaround is available, or it is determined that a fix is not
	possible or desirable.</p>
	<p>The Eclipse IP Team will give priority to contribution
	questionnaires (CQs) required to resolve Vulnerabilities.</p>
	<p>It is left to the discretion of the Security Team and project
	leadership to determine what subset of the project committers are
	best suited to resolve Vulnerabilities. The Security Team and project
	leaders may also—at their discretion—assemble external
	resources (e.g. subject matter experts) or call on the expertise of
	the Architecture Council.</p>
	<a name="Distribution"></a>
	<h2>Distribution</h2>
	<p>Once a Vulnerability has been resolved, the updated software must
	be made available to the community.</p>
	<p>At a minimum, updated software is made available via normal project
	distribution channels (e.g. downloads and update sites).</p>
	<p>The planning council must be made aware of Vulnerabilities in
	software that is part of the simultaneous release. The Planning
	Council will determine whether or not a "respin" of the simultaneous
	release repository and EPP packages is required. The Planning Council
	will coordinate the timing of the "respin" with the Project
	Leadership.</p>
	<a name="Disclosure"></a>
	<h2>Disclosure</h2>
	<p>Disclosure is initially limited to the reporter and all Eclipse
	Committers, but can be expanded to include other individuals.</p>
	<p>All Vulnerabilities must be disclosed, regardless of the
	resolution. Users and administrators of Eclipse software must made
	aware that a vulnerability exists so they can assess risk, and take
	the appropriate action to protect their users, servers and systems
	from potential exploit.</p>
	<a name="Timing"></a>
	<h3>Timing</h3>
	<p>The timing of disclosure is left to the discretion of the project
	leadership, including the Project Lead(s), PMC, and EMO(ED). In the
	absence of specific guidance from the project leadership, the
	following guidelines are recommended:</p>
	<ul>
	<li>Vulnerabilities for which there is a patch, workaround or fix,
	should be disclosed to the community immediately.</li>
	<li>Vulnerabilities—regardless of state—must be disclosed to the
	community after a maximum three months.</li>
	</ul>
	<p>Vulnerabilities need not necessarily be resolved at the time of
	disclosure.</p>
	<a name="Quiet_Disclosure"></a>
	<h3>Quiet Disclosure</h3>
	<p>
	A Vulnerability can be <i>quietly</i> disclosed by simply removing
	the 'committers_only' flag. The bug's history will record that the
	flag has been removed, and the bug will become visible for everyone
	in searches.
	</p>
	<p>In general, quiet disclosure is appropriate only for bugs that are
	identified by a committer as having been erroneously marked as
	Vulnerabilities.</p>
	<a name="Progressive_Disclosure"></a>
	<h3>Progressive Disclosure</h3>
	<p>Knowledge of a Vulnerability can be easily extended to individuals
	by adding them to the "cc" list on the bug. A Vulnerability may--at
	the discretion of the committer--be disclosed to specific
	individuals. A committer may, for example, provide access to a
	subject-matter expert to solicit help or advice. The Vulnerability
	may also be disclosed to known adopters to allow them an opportunity
	to mitigate their immediate risk and prepare for a forthcoming
	resolution.</p>
	<p>Contacts added to an unresolved Vulnerability must be individuals.
	Groups (e.g. mailing lists)--with the exception of
	security@eclipse.org--should never be copied on a Vulnerability bug.
	</p>
	<a name="Full_Disclosure"></a>
	<h3>Full Disclosure</h3>
	<p>All Vulnerabilities must ultimately be fully disclosed to the
	community at large.</p>
	<p>
	All Vulnerabilities affecting projects that participate in the
	Simultaneous Release must be reported to the Planning Council prior
	to full disclosure to the community at large. Disclosure of a
	Vulnerability must be coordinated with the distribution of the
	updated software from the Project's own distribution channels, the
	Simultaneous Release repository, and EPP packages (please see <a
	href="#Distribution" title="">Distribution</a>.
	</p>
	<p>To complete the disclosure of a Vulnerability, the committers-only
	flag must be removed from the bug and the 'security' keyword added.
	Bugs in this state are automatically reported on the security page
	and RSS feed.</p>
	<a name="Escalation"></a>
	<h3>Escalation</h3>
	<p>
	A security vulnerability may--at the discretion of the project
	leadership--be escalated to a outside body such as <a
	href="http://www.cert.org" class="external text"
	title="http://www.cert.org" rel="nofollow">CERT</a>. The EMO can
	provide assistance.
	</p>
	</div>
	</div>

	<?php
	$html = ob_get_contents();
	ob_end_clean();

	$App->generatePage('Nova', $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
	?>