|
| 1 | +<?xml version="1.0" encoding="UTF-8"?> |
| 2 | +<devbook self="ebuild-maintenance/security/"> |
| 3 | +<chapter> |
| 4 | +<title>Security</title> |
| 5 | + |
| 6 | +<section> |
| 7 | +<title>Maintainer expectations</title> |
| 8 | + |
| 9 | +<subsection> |
| 10 | +<title>Bug reports</title> |
| 11 | +<body> |
| 12 | + |
| 13 | +<p> |
| 14 | +Maintainers are expected to a file a bug on Bugzilla under the Gentoo Security |
| 15 | +product's Vulnerabilities component if a security vulnerability (even without |
| 16 | +a CVE assigned) affects their package. |
| 17 | +</p> |
| 18 | + |
| 19 | +<p> |
| 20 | +While the Gentoo Security project makes an effort to monitor CVE feeds, that |
| 21 | +is not a substitute for project-specific communications about vulnerabilities |
| 22 | +in release notes or other channels. Information often (though not always) |
| 23 | +eventually appears in CVE feeds, but usually with a significant delay. |
| 24 | +</p> |
| 25 | + |
| 26 | +<p> |
| 27 | +Triage of the bug and filling out of the Bugzilla whiteboard is appreciated |
| 28 | +but not required for the package maintainer. |
| 29 | +</p> |
| 30 | + |
| 31 | +<p> |
| 32 | +For such bug reports, the bug summary should reflect the first fixed |
| 33 | +version in the Gentoo repository, not the first fixed version released |
| 34 | +by upstream. This means unpackaged versions should not be in the title. |
| 35 | +</p> |
| 36 | + |
| 37 | +</body> |
| 38 | +</subsection> |
| 39 | + |
| 40 | +<subsection> |
| 41 | +<title>Fixed versions of packages</title> |
| 42 | +<body> |
| 43 | + |
| 44 | +<p> |
| 45 | +Upstream releases fixing security issues in a package should be packaged |
| 46 | +as soon as possible. |
| 47 | +</p> |
| 48 | + |
| 49 | +<p> |
| 50 | +Similarly, releases fixing (ideally exclusively) security problems should |
| 51 | +be stabilised on an expedited basis. The maintainer is expected to indicate |
| 52 | +how long is needed to wait for stabilisation or file the stabilisation bug |
| 53 | +themselves, making it block the security bug. |
| 54 | +</p> |
| 55 | + |
| 56 | +<p> |
| 57 | +For critical bugs, stabilisation is usually requested within 24 hours. For |
| 58 | +less serious bugs, consider the default timeline to be 7-14 days. |
| 59 | +</p> |
| 60 | + |
| 61 | +<p> |
| 62 | +Be aware that upstreams are often under pressure to release fixes quickly, |
| 63 | +occasionally resulting in regressions: hurried stabilisation should be |
| 64 | +balanced against the severity of the reported vulnerabilities and the damage |
| 65 | +that could be done from a resulting regression. |
| 66 | +</p> |
| 67 | + |
| 68 | +<p> |
| 69 | +For example, a mild security vulnerability in a networked authentication |
| 70 | +daemon, requiring special configuration to trigger a Denial of Service, might |
| 71 | +warrant waiting a couple of days if the fix touches generic code, meaning |
| 72 | +regressions could harm users outside of a fringe configuration. |
| 73 | +</p> |
| 74 | + |
| 75 | +<p> |
| 76 | +Upstream regressions from security fixes mean that old versions shouldn't |
| 77 | +be cleaned up aggressively. Security fixes have been known to break user |
| 78 | +workflows even when upstream don't view the change as a regression or a bug. |
| 79 | +</p> |
| 80 | + |
| 81 | +</body> |
| 82 | +</subsection> |
| 83 | +</section> |
| 84 | +</chapter> |
| 85 | +</devbook> |
0 commit comments