Skip to content

Commit 18a8a71

Browse files
michaelrsweetmichaelrsweet
committed
Merge in some changes to the documented security policy.
1 parent af6c35f commit 18a8a71

1 file changed

Lines changed: 74 additions & 34 deletions

File tree

‎SECURITY.md‎

Lines changed: 74 additions & 34 deletions
Original file line numberDiff line numberDiff line change
@@ -1,23 +1,9 @@
11
Security Policy
22
===============
33

4-
This file describes how security issues are reported and handled, and what the
5-
expectations are for security issues reported to this project.
6-
7-
8-
Responsible Disclosure
9-
----------------------
10-
11-
With *responsible disclosure*, a security issue (and its fix) is disclosed only
12-
after a mutually-agreed period of time (the "embargo date"). The issue and fix
13-
are shared amongst and reviewed by the key stakeholders (Linux distributions,
14-
OS vendors, etc.) and the CERT/CC. Fixes are released to the public on the
15-
agreed-upon date.
16-
17-
> Responsible disclosure applies only to production releases. A security
18-
> vulnerability that only affects unreleased code can be fixed immediately
19-
> without coordination. Vendors *should not* package and release unstable
20-
> snapshots, beta releases, or release candidates of this software.
4+
This file describes how security issues are reported and handled by
5+
OpenPrinting, and what the expectations are for security issues reported to
6+
this project.
217

228

239
Supported Versions
@@ -49,25 +35,59 @@ example:
4935
1.0b2
5036
1.0rc1
5137

38+
> *Note:* This security policy only applies to production releases. A security
39+
> vulnerability that only affects unreleased code will be fixed immediately
40+
> without coordination. Vendors *should not* package and release unstable
41+
> snapshots, beta releases, or release candidates of this software.
42+
43+
44+
Is the Issue a Bug or a Security Vulnerability?
45+
-----------------------------------------------
46+
47+
OpenPrinting has defined criteria for identifying whether issues are handled as
48+
regular project bugs or as security vulnerabilities that use the "Reporting a
49+
Vulnerability" process below.
5250

53-
Reporting a Vulnerability
54-
-------------------------
51+
The following kinds of issues are generally treated as security vulnerabilities
52+
by OpenPrinting:
5553

56-
Github supports private security advisories and OpenPrinting CUPS enabled
57-
their usage, report all security issue via them. Reporters can file a security
58-
advisory by clicking on `New issue` at tab `Issues` and choose
59-
`Report a vulnerability`. Provide details, impact, reproducer, affected
60-
versions, workarounds and patch for the vulnerability if there are any and
61-
estimate severity when creating the advisory.
54+
- Daemon/service crashes/hangs caused by a network request,
55+
- Remote code execution code via software provided by OpenPrinting,
56+
- Privilege escalation that allows unauthorized actions or information
57+
disclosure,
58+
- Common weaknesses (buffer overflow, divide-by-zero, input validation,
59+
use-after-free, etc.) that lead to a demonstrated (not theoretical) exploit.
6260

63-
Expect a response within 5 business days.
61+
The following kinds of issues are generally treated as regular bugs by
62+
OpenPrinting:
63+
64+
- Vulnerabilities caused by mis-configuration
65+
- Issues caused by incorrect API usage
66+
- Issues that only exist in non-production software
67+
68+
Regular bugs should be reported to the project using the GitHub (public) issue
69+
tracker page at <https://github.com/OpenPrinting/cups/issues>.
70+
71+
72+
Reporting a Security Vulnerability
73+
----------------------------------
74+
75+
Vulnerabilities should be reported to the project using the GitHub (private)
76+
security advisory page at
77+
<https://github.com/OpenPrinting/cups/security/advisories>.
78+
79+
Provide details, impact, reproducer, affected versions, workarounds, and a patch
80+
for the vulnerability, if applicable.
81+
82+
You can expect a response within 5 business days.
6483

6584

6685
How We Respond to Vulnerability Reports
6786
---------------------------------------
6887

69-
First, we take every report seriously. There are (conservatively) over a
70-
billion systems using CUPS, so any security issue can affect a lot of people.
88+
First, we take every report seriously. There are (conservatively) several
89+
billion devices/systems using CUPS, so any security issue can affect a lot of
90+
people.
7191

7292
Members of the OpenPrinting security team will try to verify/reproduce the
7393
reported issues in a timely fashion. Please keep in mind that many members of
@@ -84,6 +104,13 @@ scope of the issue. We assess vulnerabilities based on our supported platforms
84104
and common configurations because we need to be able to test and verify issues
85105
and fixes on those supported platforms.
86106

107+
> *Note:* GitHub uses CVSS base metrics which require the default configuration
108+
> of the affected project. This is most important for the attack vector metric
109+
> in CVSS because the default cupsd configuration only listens on the loopback
110+
> and domain socket addresses.
111+
112+
The final CVSS score determines how the vulnerability is disclosed.
113+
87114
Similar issues (if multiple vulnerabilities are reported) will be combined if
88115
they share a common root cause. We don't mean any disrespect by doing this, we
89116
just want to make sure your issues are truly and efficiently addressed in full.
@@ -92,10 +119,23 @@ Once we have verified things, we will work towards providing a fix as quickly
92119
as possible. Fixes are typically developed against the "master" branch, then
93120
backported as needed to cover shipping CUPS releases on our supported platforms.
94121

95-
Once we have the fixes ready, we request a CVE, coordinate an embargo date, and
96-
announce it on `distros@vs.openwall.org` mailing list. The embargo period is
97-
typically 7-10 days long but can be longer.
98122

99-
The embargo starts a flurry of activity - hundred of developers supporting every
100-
Linux distribution, the various BSD flavors, macOS, and ChromeOS will queue up
101-
the security updates for their respective OS releases on the embargo date.
123+
Responsible Disclosure
124+
----------------------
125+
126+
With *responsible disclosure*, the issue and its fixes are shared amongst and
127+
reviewed by the key stakeholders (Linux distributions, OS vendors, etc. on the
128+
`distros@vs.openwall.org` mailing list) and the CERT/CC. OpenPrinting requests
129+
a CVE when we have agreed-upon fixes ready.
130+
131+
If the final CVSS score is 7 or more, or if a key stakeholder requests it,
132+
OpenPrinting coordinates a mutually-agreed period of time (the "embargo date")
133+
for when the fixes will be released. Otherwise, the fixes are pushed to the
134+
public repository immediately and included in a subsequent production release
135+
when convenient.
136+
137+
> *Note:* An embargo starts a flurry of activity. Hundreds of developers
138+
> supporting every Linux distribution, the various BSD flavors, macOS, and
139+
> ChromeOS queue up security updates for their respective OS releases on the
140+
> embargo date. OpenPrinting wants to limit the embargo process to high
141+
> severity issues to better manage limited developer resources.

0 commit comments

Comments
 (0)