Update of /cvsroot/fink/scripts/installer/dmg/doc/security
In directory
sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6079/scripts/installer/dmg/doc/security
Added Files:
sec-policy.en.html sec-policy.fr.html sec-policy.ja.html
sec-policy.zh.html
Log Message:
Adding security.fr.xml
--- NEW FILE: sec-policy.en.html ---
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd";>
<html><head><meta http-equiv="Content-Type" content="text/html;
charset=utf-8"><title>Fink Documentation - General Fink security policy for accepted
packages.</title></head><body>
<table width="100%" cellspacing="0">
<tr valign="bottom">
<td align="center">
Available Languages: |
English |
<a href="policy.fr.html">Français</a> |
<a href="policy.ja.html">日本語 (Nihongo)</a> |
<a href="policy.zh.html">中文 (简) (Simplified Chinese)</a> |
</td>
</tr>
</table>
<h1 style="text-align: center;">General Fink security policy for accepted
packages.</h1>
<p>This document explains security incident handling for packages that
have been accepted by Fink. While the main responsibility for every
accepted package in Fink remains with the respective maintainer,
Fink recognizes the necessity to offer a uniform policy on how to
react to security incidents found in software which are offered as
Fink packages. Every package maintainer is required to comply with it.</p>
<h2>Contents</h2><ul><li><a href="#respo"><b>1 Responsibility</b></a><ul><li><a
href="#respo.who">1.1 Who is responsible?</a></li><li><a href="#respo.contact">1.2
Whom shall I contact?</a></li><li><a href="#respo.prenotifications">1.3
Pre-notifications</a></li><li><a href="#respo.response">1.4
Response</a></li></ul></li><li><a href="#severity"><b>2 Response times and immediate
actions.</b></a><ul><li><a href="#severity.resptimes">2.1 Response
times</a></li><li><a href="#severity.forced">2.2 Forced
updates</a></li></ul></li><li><a href="#sources"><b>3 Incident
Sources</b></a><ul><li><a href="#sources.sources">3.1 Acceptable Incident
Sources.</a></li></ul></li><li><a href="#updating"><b>4 Security update
procedure.</b></a><ul><li><a href="#updating.procedure">4.1 Adding security related
updates.</a></li><li><a href="#updating.moving">4.2 Unstable to stable
moves.</a></li></ul></li><li><a href="#notification"><b>5 Sending
notifications</b></a><ul><li><a href="#notification.who">5.1 Who may send
them?</a></li><li><a href="#notification.how">5.2 How to submit
</a></li></ul></li></ul><h2><a name="respo">1 Responsibility</a></h2>
<h3><a name="respo.who">1.1 Who is responsible?</a></h3>
<p>Every Fink package has a Maintainer. The maintainer of a
particular package can be found by typing <tt style="white-space:
nowrap;">fink info
packagename</tt> at the command line prompt. This will return
a listing with a field similar to this one: Maintainer: Fink
Core Group
<[EMAIL PROTECTED]>. The
maintainer has full responsibility for his/her package(s).</p>
<h3><a name="respo.contact">1.2 Whom shall I contact?</a></h3>
<p>If there are security incidents within a certain piece of
packaged software, you should notify the maintainer of that
package as well as the <b>Fink Core Team</b>. The email of the
maintainer can be found within the packages info, and the email
of the <b>Fink Core Team</b> is
[EMAIL PROTECTED] </p>
<h3><a name="respo.prenotifications">1.3 Pre-notifications</a></h3>
<p>Serious security incidents in software packaged by Fink might
require you to pre-notify the maintainer of that package. Since
it is possible that the maintainer cannot be reached in a timely
manner, pre-notifications should always also be submitted to the
<b>Fink Security Team</b>. Each team members e-mail is
listed individually later on in this document. Please note that
[EMAIL PROTECTED] is a publically archived mailing
list, private pre-notifications should <b>never</b> be sent to
that list.</p>
<h3><a name="respo.response">1.4 Response</a></h3>
<p>Submitted reports about a security incident will be answered by
the <b>Fink Core Team</b>. Each maintainer is required by Fink
to acknowledge the reported issue individually. In the unlikely
event that the maintainer is not available and the maintainer
has not acknowledged the report within 24 hours, a note should
be sent to the <b>Fink Core Team</b> informing the team that
the maintainer might be unresponsive. </p>
<p>In the event that you attempted to notify the maintainer of the
package in question but the mail system returned a delivery
error for that email you should notify the <b>Fink Core
Team</b> immediately to inform them that the maintainer is
unreachable and that the package may be updated irrespective of
the maintainer. </p>
<h2><a name="severity">2 Response times and immediate actions.</a></h2>
<p>Response time and actions taken greatly depend on the severity of
the loss introduced by a particular flaw in the software that
has been packaged for Fink. In any case the <b>Fink Core
Team</b> will take immediate action whenever it feels it is
necessary to protect the Fink user community.</p>
<h3><a name="severity.resptimes">2.1 Response times</a></h3>
<p>Each package should strive to meet the following response times.
For some types of vulnerabilities the <b>Fink Core Team</b>
might choose to take immediate action. If that is the case, one
of the Core Team members will notify the maintainer of the
package in question. Also, keep in mind that, while we strive to
meet these response times, Fink is a volunteer effort, and they
cannot be guaranteed.</p>
<table border="0" cellpadding="0" cellspacing="10"><tr valign="bottom"><th
align="left">Vulnerability</th><th align="left">Repsonse time</th></tr><tr
valign="top"><td>remote root exploit</td><td>
<p>minimum: <b>immediate</b>; maximum: <b>12</b> hours.</p>
</td></tr><tr valign="top"><td>local root exploit</td><td>
<p>minimum: <b>12</b> hours; maximum: <b>36</b> hours.</p>
</td></tr><tr valign="top"><td>remote DOS</td><td>
<p>minimum: <b>6</b> hours; maximum: <b>12</b> hours.</p>
</td></tr><tr valign="top"><td>local DOS</td><td>
<p>minimum: <b>24</b> hours; maximum: <b>72</b> hours.</p>
</td></tr><tr valign="top"><td>remote data corruption</td><td>
<p>minimum: <b>12</b> hours; maximum: <b>24</b> hours.</p>
</td></tr><tr valign="top"><td>local data corruption</td><td>
<p>minimum: <b>24</b> hours; maximum: <b>72</b> hours.</p>
</td></tr></table>
<h3><a name="severity.forced">2.2 Forced updates</a></h3>
<p>A member of the <b>Fink Core Team</b> might choose to update a
package without waiting for the package's maintainer to take
action. This is called a forced update. Not
meeting the maximum required response time for a particular
vulnerability in a Fink package also results in a forced
update of that package.</p>
<h2><a name="sources">3 Incident Sources</a></h2>
<h3><a name="sources.sources">3.1 Acceptable Incident Sources.</a></h3>
<p>As submitter of a security incident in Fink-packaged software you
have to ensure that the vulnerability of the software also
exists on Mac OS X. It is the responsibility of the notifying party
to ensure that one of the following sources reinforces the
reported issue for the particular software in question.</p>
<ol>
<li>
<b>AIXAPAR</b>: AIX APAR (Authorised Problem Analysis Report)</li>
<li>
<b>APPLE</b>: Apple Security Update</li>
<li>
<b>ATSTAKE</b>: @stake security advisory</li>
<li>
<b>AUSCERT</b>: AUSCERT advisory</li>
<li>
<b>BID</b>: Security Focus Bugtraq ID database entry</li>
<li>
<b>BINDVIEW</b>: BindView security advisory</li>
<li>
<b>BUGTRAQ</b>: Posting to Bugtraq mailing list</li>
<li>
<b>CALDERA</b>: Caldera security advisory</li>
<li>
<b>CERT</b>: CERT/CC Advisories</li>
<li>
<b>CERT-VN</b>: CERT/CC vulnerability note</li>
<li>
<b>CIAC</b>: DOE CIAC (Computer Incident Advisory Center)
bulletins</li>
<li>
<b>CONECTIVA</b>: Conectiva Linux advisory</li>
<li>
<b>CONFIRM:</b> URL to location where vendor confirms that
the problem exists</li>
<li>
<b>DEBIAN</b>: Debian Linux Security Information</li>
<li>
<b>EEYE</b>: eEye security advisory</li>
<li>
<b>EL8</b>: EL8 advisory</li>
<li>
<b>ENGARDE</b>: En Garde Linux advisory</li>
<li>
<b>FEDORA</b>: Fedora Project security advisory</li>
<li>
<b>FULLDISC</b>: Full-Disclosure mailing list</li>
<li>
<b>FreeBSD</b>: FreeBSD security advisory</li>
<li>
<b>GENTOO</b>: Gentoo Linux security advisory</li>
<li>
<b>HERT</b>: HERT security advisory</li>
<li>
<b>HP</b>: HP security advisories</li>
<li>
<b>IBM</b>: IBM ERS/BRS advisories</li>
<li>
<b>IMMUNIX</b>: Immunix Linux advisory</li>
<li>
<b>INFOWAR</b>: INFOWAR security advisory</li>
<li>
<b>ISS</b>: ISS Security Advisory</li>
<li>
<b>KSRT</b>: KSR[T] Security Advisory</li>
<li>
<b>L0PHT</b>: L0pht Security Advisory</li>
<li>
<b>MANDRAKE</b>: Linux-Mandrake advisory</li>
<li>
<b>MISC</b>: generic reference from an URL </li>
<li>
<b>MLIST</b>: generic reference form for miscellaneous
mailing lists</li>
<li>
<b>NAI</b>: NAI Labs security advisory</li>
<li>
<b>NETECT</b>: Netect security advisory</li>
<li>
<b>NetBSD</b>: NetBSD Security Advisory</li>
<li>
<b>OPENBSD</b>: OpenBSD Security Advisory</li>
<li>
<b>REDHAT</b>: Security advisories</li>
<li>
<b>RSI</b>: Repent Security, Inc. security advisory</li>
<li>
<b>SEKURE</b>: Sekure security advisory</li>
<li>
<b>SF-INCIDENTS</b>: posting to Security Focus Incidents
mailing list</li>
<li>
<b>SGI</b>: SGI Security Advisory</li>
<li>
<b>SLACKWARE</b>: Slackware security advisory</li>
<li>
<b>SNI</b>: Secure Networks, Inc. security advisory</li>
<li>
<b>SUN</b>: Sun security bulletin</li>
<li>
<b>SUNALERT</b>: Sun security alert</li>
<li>
<b>SUNBUG</b>: Sun bug ID</li>
<li>
<b>SUSE</b>: SuSE Linux: Security Announcements</li>
<li>
<b>TRUSTIX</b>: Trustix Security Advisory</li>
<li>
<b>TURBO</b>: TurboLinux advisory</li>
<li>
<b>VULN-DEV</b>: Posting to VULN-DEV mailing list</li>
<li>
<b>VULNWATCH</b>: VulnWatch mailing list</li>
<li>
<b>XF</b>: X-Force Vulnerability Database</li>
<li>
<b>CVE</b>: CVE Candidates </li>
</ol>
<p>The above keywords are in full compliance with the CVE
recommended keyword list found <a
href="http://www.cve.mitre.org/cve/refs/refkey.html";>here</a>. </p>
<h2><a name="updating">4 Security update procedure.</a></h2>
<h3><a name="updating.procedure">4.1 Adding security related updates.</a></h3>
<p>Security updates may only be applied once they have been verified
by the original Author of the software which has been packaged
for Fink and found to be vulnerable to a security issue. Before
an update one or more of the following conditions <b>have</b>
to be met:</p>
<ul>
<li>The author of the software has contacted the maintainer
and/or the <b>Fink Core Team</b> directly providing a
patch or work around to a vulnerability.</li>
<li>One of the keyword-denoted sources has issued a security
bulletin with updated sources for the software packaged for
Fink in question.</li>
<li>A patch has been issued to one of the following
keyword-denoted sources:
BUGTRAQ,FULLDISC,SF-INCIDENTS,VULN-DEV.</li>
<li>An official security bulletin has been issued and assigned
CVE Candidate status, describing the vulnerability,
supplying a work around, patch or link to updated sources.</li>
<li>Pre-notification has been sent to the maintainer and/or the
<b>Fink Core Team</b> directly providing a patch or
work around to a vulnerability asking to take action.</li>
</ul>
<h3><a name="updating.moving">4.2 Unstable to stable moves.</a></h3>
<p>Security updates for a specific package will first be applied to
the unstable tree. After a waiting period of no less than
<b>12</b> hours the packages' info (and eventually patch) files will
be moved into the
stable tree as well. The retention period shall be used to
carefully observe whether the updated package works and the
security update does not introduce any new issues.</p>
<h2><a name="notification">5 Sending notifications</a></h2>
<p>Some users might choose not to update their software too
frequently. To ensure that those who install their packages from
source are using updated packages which have been reported to
have security issues as soon as possible, a maintainer may call
for a notification to be sent to the Fink announcement list.</p>
<h3><a name="notification.who">5.1 Who may send them?</a></h3>
<p>These announcements may only be sent by the <b>Fink Security
Team</b>. Most announcement will be sent from
[EMAIL PROTECTED] signed by the PGP key with the
fingerprint:
</p>
<ul>
<li>
FD77 F0B7 5C65 F546 EB08 A4EC 3CCA 1A32 7E24
291E.
</li>
<li>Found at
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7E24291E</li></ul>
<p>
The above is intentionally not marked as a link.</p>
<p> Other authorised Team members are: (here you add your email +
public key like I did above)</p><p>
[EMAIL PROTECTED] signed by the PGP key with the fingerprint:</p>
<ul>
<li>
4D67 1997 DD32 AE8E D7ED 9C79 8491 2AB7 DF3B 6004.</li>
<li>
Found at
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDF3B6004
</li>
</ul>
<h3><a name="notification.how">5.2 How to submit </a></h3>
<p> To ensure that a common look for security notifications is met,
all security notices <b>must</b> follow the following common
template. </p>
<pre> ID: FINK-YYYY-MMDD-NN
Reported: YYYY-MM-DD
Updated: YYYY-MM-DD
Package: package-name
Affected: <= versionid
Maintainer: maintainer-name
Tree(s): 10.3/stable, 10.3/unstable,
10.2-gcc3.3/stable,10.2-gcc3.3/unstable
Mac OS X version: 10.3, 10.2
Fix: patch|upstream
Updated by: maintainer|forced update (Email)
Description: A short description describing the issue.
References: KEYWORD (see above)
Ref-URL: URL
</pre>
<p>A sample report could look somewhat like this:</p>
<pre> ID: FINK-2004-06-01
Reported: 2004-06-09
Updated: 2004-06-09
Package: cvs
Affected: <= 1.11.16, <= 1.12.8
Maintainer: Sylvain Cuaz
Tree(s): 10.3/stable, 10.3/unstable,
10.2-gcc3.3/stable,10.2-gcc3.3/unstable
Mac OS X version: 10.3, 10.2
Fix: upstream
Updated by: forced update ([EMAIL PROTECTED])
Description: Multiple vulnerabilities in CVS found by Ematters
Security.
References: BID
Ref-URL: http://www.securityfocus.com/bid/10499
References: CVE
Ref-URL:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0414
References: CVE
Ref-URL:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0416
References: CVE
Ref-URL:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0417
References: CVE
Ref-URL:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0418
References: FULLDISCURL
Ref-URL:
http://lists.netsys.com/pipermail/full-disclosure/2004-June/022441.html
References: MISC
Ref-URL:
http://security.e-matters.de/advisories/092004.html </pre>
<p> Please note that the <b>Affected</b> keyword refers to all vulnerable
software versions not
only those that might be packaged for Fink. The sample report shows this
clearly.</p>
<hr><h2>Copyright Notice</h2><p>Copyright (c) 2001 Christoph Pfisterer,
Copyright (c) 2001-2004 The Fink Project.
You may distribute this document in print for private purposes,
provided the document and this copyright notice remain complete and
unmodified. Any commercial reproduction and any online publication
requires the explicit consent of the author.</p><hr><p>Generated from <i>$Fink:
sec-policy.en.xml,v 1.14 2004/07/10 13:51:48 dmalloc Exp $</i></p></body></html>
--- NEW FILE: sec-policy.ja.html ---
(This appears to be a binary file; contents omitted.)
--- NEW FILE: sec-policy.fr.html ---
(This appears to be a binary file; contents omitted.)
--- NEW FILE: sec-policy.zh.html ---
(This appears to be a binary file; contents omitted.)
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Fink-commits mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-commits
