Available Languages: | Deutsch | English | Français | 日本語 (Nihongo) | Português | 中文 (简) (Simplified Chinese) |

General Fink security policy for accepted packages.

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.


1 Responsibility

1.1 Who is responsible?

Every Fink package has a Maintainer. The maintainer of a particular package can be found by typing fink info packagename at the command line prompt. This will return a listing with a field similar to this one: Maintainer: Fink Core Group <fink-core@lists.sourceforge.net>. The maintainer has full responsibility for his/her package(s).

1.2 Whom shall I contact?

If there are security incidents within a certain piece of packaged software, you should notify the maintainer of that package as well as the Fink Core Team. The email of the maintainer can be found within the packages info, and the email of the Fink Core Team is fink-core@lists.sourceforge.net

1.3 Pre-notifications

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 Fink Security Team. Each team members e-mail is listed individually later on in this document. Please note that fink-core@lists.sourceforge.net is a publically archived mailing list, private pre-notifications should never be sent to that list.

1.4 Response

Submitted reports about a security incident will be answered by the Fink Core Team. 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 Fink Core Team informing the team that the maintainer might be unresponsive.

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 Fink Core Team immediately to inform them that the maintainer is unreachable and that the package may be updated irrespective of the maintainer.

2 Response times and immediate actions.

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 Fink Core Team will take immediate action whenever it feels it is necessary to protect the Fink user community.

2.1 Response times

Each package should strive to meet the following response times. For some types of vulnerabilities the Fink Core Team 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.

VulnerabilityResponse time
remote root exploit

minimum: immediate; maximum: 12 hours.

local root exploit

minimum: 12 hours; maximum: 36 hours.

remote DOS

minimum: 6 hours; maximum: 12 hours.

local DOS

minimum: 24 hours; maximum: 72 hours.

remote data corruption

minimum: 12 hours; maximum: 24 hours.

local data corruption

minimum: 24 hours; maximum: 72 hours.

2.2 Forced updates

A member of the Fink Core Team 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.

3 Incident Sources

3.1 Acceptable Incident Sources.

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.

  1. AIXAPAR: AIX APAR (Authorised Problem Analysis Report)
  2. APPLE: Apple Security Update
  3. ATSTAKE: @stake security advisory
  4. AUSCERT: AUSCERT advisory
  5. BID: Security Focus Bugtraq ID database entry
  6. BINDVIEW: BindView security advisory
  7. BUGTRAQ: Posting to Bugtraq mailing list
  8. CALDERA: Caldera security advisory
  9. CERT: CERT/CC Advisories
  10. CERT-VN: CERT/CC vulnerability note
  11. CIAC: DOE CIAC (Computer Incident Advisory Center) bulletins
  12. CONECTIVA: Conectiva Linux advisory
  13. CONFIRM: URL to location where vendor confirms that the problem exists
  14. DEBIAN: Debian Linux Security Information
  15. EEYE: eEye security advisory
  16. EL8: EL8 advisory
  17. ENGARDE: En Garde Linux advisory
  18. FEDORA: Fedora Project security advisory
  19. FULLDISC: Full-Disclosure mailing list
  20. FreeBSD: FreeBSD security advisory
  21. GENTOO: Gentoo Linux security advisory
  22. HERT: HERT security advisory
  23. HP: HP security advisories
  24. IBM: IBM ERS/BRS advisories
  25. IMMUNIX: Immunix Linux advisory
  26. INFOWAR: INFOWAR security advisory
  27. ISS: ISS Security Advisory
  28. KSRT: KSR[T] Security Advisory
  29. L0PHT: L0pht Security Advisory
  30. MANDRAKE: Linux-Mandrake advisory
  31. MISC: generic reference from an URL
  32. MLIST: generic reference form for miscellaneous mailing lists
  33. NAI: NAI Labs security advisory
  34. NETECT: Netect security advisory
  35. NetBSD: NetBSD Security Advisory
  36. OPENBSD: OpenBSD Security Advisory
  37. REDHAT: Security advisories
  38. RSI: Repent Security, Inc. security advisory
  39. SEKURE: Sekure security advisory
  40. SF-INCIDENTS: posting to Security Focus Incidents mailing list
  41. SGI: SGI Security Advisory
  42. SLACKWARE: Slackware security advisory
  43. SNI: Secure Networks, Inc. security advisory
  44. SUN: Sun security bulletin
  45. SUNALERT: Sun security alert
  46. SUNBUG: Sun bug ID
  47. SUSE: SuSE Linux: Security Announcements
  48. TRUSTIX: Trustix Security Advisory
  49. TURBO: TurboLinux advisory
  50. VULN-DEV: Posting to VULN-DEV mailing list
  51. VULNWATCH: VulnWatch mailing list
  52. XF: X-Force Vulnerability Database
  53. CVE: CVE Candidates

The above keywords are in full compliance with the CVE recommended keyword list found here.

4 Security update procedure.

4.1 Adding security related updates.

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 have to be met:

4.2 Unstable to stable moves.

Security updates for a specific package will first be applied to the unstable tree. After a waiting period of no less than 12 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.

5 Sending notifications

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.

5.1 Who may send them?

These announcements may only be sent by the Fink Security Team. Most announcement will be sent from dmalloc@users.sourceforge.net signed by the PGP key with the fingerprint:

The above is intentionally not marked as a link.

Other authorised Team members are: (here you add your email + public key like I did above)

peter@pogma.com signed by the PGP key with the fingerprint:

ranger@befunk.com signed by the PGP key with the fingerprint:

5.2 How to submit

To ensure that a common look for security notifications is met, all security notices must follow the following common template.

                        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 

A sample report could look somewhat like this:

 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 (dmalloc@users.sourceforge.net)
                        Description: Multiple vulnerabilities in CVS found by Ematters
			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 

Please note that the Affected keyword refers to all vulnerable software versions not only those that might be packaged for Fink. The sample report shows this clearly.

Copyright Notice

Copyright (c) 2001 Christoph Pfisterer, Copyright (c) 2001-2020 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.

Generated from $Fink: sec-policy.en.xml,v 1.16 2009/03/31 01:41:35 monipol Exp $