/[gentoo]/xml/htdocs/security/en/vulnerability-policy.xml
Gentoo

Diff of /xml/htdocs/security/en/vulnerability-policy.xml

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

Revision 1.21 Revision 1.24
… …
2<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> 2<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
3<guide link="/security/en/vulnerability-policy.xml"> 3<guide link="/security/en/vulnerability-policy.xml">
4<title>Gentoo Linux Vulnerability Treatment Policy</title> 4<title>Gentoo Linux Vulnerability Treatment Policy</title>
5<author title="Author"> 5<author title="Author">
6 <mail link="koon@gentoo.org">Thierry Carrez</mail> 6 <mail link="koon@gentoo.org">Thierry Carrez</mail>
7</author> 7</author>
8<author title="Author"> 8<author title="Author">
9 <mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail> 9 <mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail>
10</author> 10</author>
11<author title="Author"> 11<author title="Author">
12 <mail link="vorlon@gentoo.org">Matthias Geerdsen</mail> 12 <mail link="vorlon@gentoo.org">Matthias Geerdsen</mail>
13</author> 13</author>
14<author title="Author"> 14<author title="Author">
15 <mail link="rbu@gentoo.org">Robert Buchholz</mail> 15 <mail link="rbu@gentoo.org">Robert Buchholz</mail>
16</author> 16</author>
17<author title="Author">
18 <mail link="a3li@gentoo.org">Alex Legler</mail>
19</author>
17 20
18<abstract> 21<abstract>
19This document describes the policy used in Gentoo Linux to treat 22This document describes the policy used in Gentoo Linux to treat
20vulnerabilities discovered in the packages made available to our 23vulnerabilities discovered in the packages made available to our
21users. 24users.
22</abstract> 25</abstract>
23 26
24<!-- The content of this document is licensed under the CC-BY-SA license --> 27<!-- The content of this document is licensed under the CC-BY-SA license -->
25<!-- See http://creativecommons.org/licenses/by-sa/1.0 --> 28<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
26<license/> 29<license/>
27 30
28<version>1.2.7</version> 31<version>1.4</version>
29<date>2009-04-14</date> 32<date>2012-02-02</date>
30 33
31<chapter> 34<chapter>
32<title>Scope</title> 35<title>Scope</title>
33<section> 36<section>
34<title>Supported architectures</title> 37<title>Supported architectures</title>
35<body> 38<body>
36 39
37<p> 40<p>
38Gentoo Linux is offered on many different architectures. Some of these 41Gentoo Linux is offered on many different architectures. Some of these
39architectures have more developers than others and, as such, are able to 42architectures have more developers than others and, as such, are able to
40respond to new security vulnerabilities more quickly. While the ultimate goal 43respond to new security vulnerabilities more quickly. While the ultimate goal
41of the Gentoo Security project is to ensure that all architectures receive 44of the Gentoo Security project is to ensure that all architectures receive
42security fixes at the same time, we must also balance that against releasing 45security fixes at the same time, we must also balance that against releasing
43security fixes and GLSAs as quickly as possible so that the majority of our 46security fixes and GLSAs as quickly as possible so that the majority of our
44users are informed and protected. 47users are informed and protected.
45</p> 48</p>
46 49
47<p> 50<p>
48For this reason, the security team separates Gentoo architectures into two 51For this reason, the Security Team separates Gentoo architectures into two
49groups, <b>supported</b> and <b>unsupported</b>: 52groups, <b>supported</b> and <b>unsupported</b>:
50</p> 53</p>
51 54
52<ul> 55<ul>
53<li><b>Supported:</b> these architectures must have a stable fix committed 56<li><b>Supported:</b> these architectures must have a stable fix committed
54before the GLSA can be released</li> 57before the GLSA can be released</li>
55<li><b>Unsupported:</b> these architectures will be notified of new 58<li><b>Unsupported:</b> these architectures will be notified of new
56vulnerabilities (cc on relevant bugs), however, we will not wait for a stable 59vulnerabilities (cc on relevant bugs), however, we will not wait for a stable
57fix on these arches before issuing the GLSA and closing the bug</li> 60fix on these arches before issuing the GLSA and closing the bug</li>
58</ul> 61</ul>
59 62
60<p> 63<p>
61Here is the list of currently supported architectures: 64Here is the list of currently supported architectures:
62</p> 65</p>
63 66
… …
94supported by the Gentoo Security project: 97supported by the Gentoo Security project:
95</p> 98</p>
96 99
97<ul> 100<ul>
98<li>Appoint a developer who is the primary point of contact for security 101<li>Appoint a developer who is the primary point of contact for security
99issues (Architecture Security Liaison) related to your arch: This person is 102issues (Architecture Security Liaison) related to your arch: This person is
100responsible for ensuring that security bugs are adequately remediated on 103responsible for ensuring that security bugs are adequately remediated on
101their particular architecture</li> 104their particular architecture</li>
102<li>Agree to adhere to the published timelines for testing and 105<li>Agree to adhere to the published timelines for testing and
103marking packages as stable</li> 106marking packages as stable</li>
104</ul> 107</ul>
105 108
106</body> 109</body>
107</section> 110</section>
108<section> 111<section>
109<title>Release Engineering</title>
110<body>
111<p>
112The Release Engineering ("releng") project appoints a developer to be the
113primary point of contact for security issues.
114</p>
115<p>
116Release Engineering informs the Gentoo Security Project when a first tree
117snapshot is taken for media releases. Beginning with the first snapshot until
118the official media release ("release preparation period"), Release Engineering
119(the appointed security liaison in case of confidential issues) should be cc'd
120on each security bug entering the stabilization phase.
121</p>
122</body>
123</section>
124<section>
125<title>Kernels</title> 112<title>Kernels</title>
126<body> 113<body>
127 114
128<p> 115<p>
129Currently kernels are not covered by the GLSA release process. 116Kernels are not covered by the GLSA release process.
130Vulnerabilities must still be reported and will be fixed, but 117Vulnerabilities must still be reported and will be fixed, but
131<e>no GLSA will be issued</e> when everything is solved. 118<b>no GLSA will be issued</b> when everything is solved.
132</p> 119</p>
133 120
134<note> 121<note>
135This policy should be changed when new tools are added to cover 122The <uri link="http://git.overlays.gentoo.org/gitweb/?p=proj/kernel-check.git;a=summary">kernel-check</uri>
136security vulnerabilities affecting the different kernel sources. 123utility is being developed to provide Kernel security information.
124This policy should be updated accordingly when it is ready.
137</note> 125</note>
138 126
139</body> 127</body>
140</section> 128</section>
141<section> 129<section>
142<title>Non-stable packages</title> 130<title>Non-stable packages</title>
143<body> 131<body>
144 132
145<p> 133<p>
146Sometimes a vulnerability is found in a package that is not part of the stable 134Sometimes a vulnerability is found in a package that is not part of the stable
147trees. This is the case when the vulnerability is a security regression in a 135trees. This is the case when the vulnerability is a security regression in a
148newer (~ARCH) ebuild, but the older (stable) packages are not affected, or when 136newer (~ARCH) ebuild, but the older (stable) packages are not affected, or when
149the package has never had any stable ebuilds in the tree. 137the package has never had any stable ebuilds in the tree.
150In this case the vulnerability must still be reported and will be fixed, but 138In this case the vulnerability must still be reported and will be fixed, but
151<e>no GLSA will be issued</e> when everything is solved. 139<b>no GLSA will be issued</b> when everything is solved.
152</p> 140</p>
153 141
154<note> 142<note>
155This policy might be changed when our tools support more complex 143This policy might be changed when our tools support more complex
156upgrade paths and if a sufficient number of GLSA coordinators join 144upgrade paths and if a sufficient number of GLSA coordinators join
157the security team. 145the Security Team.
158</note> 146</note>
159 147
160</body> 148</body>
161</section> 149</section>
162</chapter> 150</chapter>
163 151
164<chapter> 152<chapter>
165<title>Vulnerability feed</title> 153<title>Vulnerability feed</title>
166<section> 154<section>
167<title>Published vulnerabilities</title> 155<title>Published vulnerabilities</title>
168<body> 156<body>
169 157
170<p> 158<p>
171Each vulnerability should initially be entered as a 159Each vulnerability should initially be entered as a
172<uri link="https://bugs.gentoo.org">Bugzilla</uri> entry with 160<uri link="https://bugs.gentoo.org">Bugzilla</uri> entry with
173product "Gentoo Security" and component "Vulnerabilities" (assigned to 161product "Gentoo Security" and component "Vulnerabilities" (assigned to
174<mail link="security@gentoo.org">security@gentoo.org</mail>). 162<mail link="security@gentoo.org">security@gentoo.org</mail>).
175Major security lists should have official scouts assigned to them which 163Major security lists should have official scouts assigned to them which
176should ensure that all vulnerabilities announced on these lists get a 164should ensure that all vulnerabilities announced on these lists get a
177security bugzilla entry. 165security Bugzilla entry.
178</p> 166</p>
179 167
180</body> 168</body>
181</section> 169</section>
182<section> 170<section>
183<title>Confidential vulnerabilities</title> 171<title>Confidential vulnerabilities</title>
184<body> 172<body>
185 173
186<p> 174<p>
187Confidential vulnerabilities (for example coming from developer's direct 175Confidential vulnerabilities (for example coming from developer's direct
188communication or restricted vendor-sec lists) should follow a specific 176communication or restricted lists) must follow a specific procedure.
189procedure. They should not appear as a public 177They should not appear as a public bugzilla entry, but only in
190bugzilla entry, but only in security-restricted media like a private 178security-restricted media like a private bugzilla section or the GLSAMaker tool.
191bugzilla section or the GLSAMaker tool. They should get
192corrected using private communication channels between the GLSA coordinator 179They should get corrected using private communication channels between the GLSA
193and the package maintainer. 180coordinator and the package maintainer.
194</p> 181</p>
195 182
196<note> 183<note>
197Communication for confidential vulnerabilities should be properly encrypted. 184Communication for confidential vulnerabilities should be properly encrypted.
198They should be sent to specific security team members and encrypted with 185They should be sent to specific Security Team members and encrypted with
199their GPG key. The list of the security team members is available at 186their GPG key. The list of the Security Team members is available at
200<uri link="http://security.gentoo.org">security.gentoo.org</uri>, their key 187<uri link="http://security.gentoo.org">security.gentoo.org</uri>, their key
201IDs can be looked up on the 188IDs can be looked up on the
202<uri link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">Gentoo 189<uri link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">Gentoo
203Linux Developers List</uri> 190Linux Developers List</uri>
204and their keys can be retrieved from the 191and their keys can be retrieved from the
205<uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri> keyserver. 192<uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri> keyserver.
193The use of IRC and other unencrypted messaging methods is discouraged.
206</note> 194</note>
207 195
208</body> 196</body>
209</section> 197</section>
210</chapter> 198</chapter>
211 199
212<chapter> 200<chapter>
213<title>Dispatch</title> 201<title>Dispatch</title>
214<section> 202<section>
215<title>Severity level</title> 203<title>Severity level</title>
216<body> 204<body>
217 205
218<p> 206<p>
219In order to seed the appropriate reaction times and escalation procedures, we 207In order to seed the appropriate reaction times and escalation procedures, we
220need to assign a severity level to each vulnerability. This severity 208need to assign a severity level to each vulnerability. This severity
… …
300<tr> 288<tr>
301 <ti>Global service compromise: Denial of Service, passwords, full 289 <ti>Global service compromise: Denial of Service, passwords, full
302 database leaks, data loss (symlink attacks)</ti> 290 database leaks, data loss (symlink attacks)</ti>
303 <ti>3</ti> 291 <ti>3</ti>
304 <ti>normal</ti> 292 <ti>normal</ti>
305</tr> 293</tr>
306<tr> 294<tr>
307 <ti>Others: Cross-Site Scripting, information leak...</ti> 295 <ti>Others: Cross-Site Scripting, information leak...</ti>
308 <ti>4</ti> 296 <ti>4</ti>
309 <ti>low</ti> 297 <ti>low</ti>
310</tr> 298</tr>
311</table> 299</table>
312 300
313<p> 301<p>
314Here is the table of the resulting severity levels. They should be set 302Here is the table of the resulting severity levels. They should be set
315to the bugzilla severity level of the same name: 303to the Bugzilla severity level of the same name:
316</p> 304</p>
317 305
318<table> 306<table>
319<tr> 307<tr>
320 <th>Severity level</th> 308 <th>Severity level</th>
321 <th>Corresponding evaluations</th> 309 <th>Corresponding evaluations</th>
322 <th>Target delay</th> 310 <th>Target delay</th>
323 <th>GLSA</th> 311 <th>GLSA</th>
324</tr> 312</tr>
325<tr> 313<tr>
326 <ti>Blocker</ti> 314 <ti>Blocker</ti>
327 <ti>A0, B0</ti> 315 <ti>A0, B0</ti>
328 <ti>1 day</ti> 316 <ti>1 day</ti>
329 <ti>yes</ti> 317 <ti>yes</ti>
330</tr> 318</tr>
… …
377wrangler and do the following tasks as soon as a new vulnerability 365wrangler and do the following tasks as soon as a new vulnerability
378enters <uri link="https://bugs.gentoo.org">Bugzilla</uri>: 366enters <uri link="https://bugs.gentoo.org">Bugzilla</uri>:
379</p> 367</p>
380 368
381<ul> 369<ul>
382<li>checking for duplicates: if the bug describes a vulnerability already 370<li>checking for duplicates: if the bug describes a vulnerability already
383 reported it should be resolved as DUPLICATE</li> 371 reported it should be resolved as DUPLICATE</li>
384<li>checking for wrong component: if the bug is not about a vulnerability 372<li>checking for wrong component: if the bug is not about a vulnerability
385 its component should be changed appropriately</li> 373 its component should be changed appropriately</li>
386<li>checking if the bug is really a vulnerability and that it affects a 374<li>checking if the bug is really a vulnerability and that it affects a
387 Gentoo Linux package, otherwise resolve the bug as INVALID</li> 375 Gentoo Linux package, otherwise resolve the bug as INVALID</li>
388</ul> 376</ul>
389 377
390<p> 378<p>
391During this phase it may be necessary to ask the reporter for details. The bug 379During this phase it may be necessary to ask the reporter for details. The bug
392remains with status NEW as long as necessary. When (if) the bug passes these 380remains with status UNCONFIRMED or CONFIRMED as long as necessary.
393sanity tests, it should be accepted and the bug wrangler should do the 381When (if) the bug passes these sanity tests, it should be marked as IN_PROGRESS
394following: 382and the bug wrangler should do the following:
395</p> 383</p>
396 384
397<ul> 385<ul>
398<li>rename the bug so that it includes category/package-name at start 386<li>rename the bug so that it includes category/package-name at start
399 (for example: "net-mail/clamav: DoS using RAR files")</li> 387 (for example: <e>net-mail/clamav: DoS using RAR files</e>)</li>
388<li>remove version information in the bug title if there is no fixed version
389 available. Bug titles like <e>&lt;=category/package-1.2.3</e>, where 1.2.3
390 is the latest version of the package, should be avoided.</li>
400<li>evaluate and assign a severity level (see above)</li> 391<li>evaluate and assign a severity level (see above)</li>
401<li>set the status to ASSIGNED</li> 392<li>set the status to IN_PROGRESS</li>
402<li>seed the status whiteboard to the correct severity code and status</li> 393<li>seed the status whiteboard to the correct severity code and status</li>
403<li>cc package maintainers to the bug according to package metadata</li> 394<li>cc package maintainers to the bug according to package metadata</li>
404<li>set the URL field to an upstream bug or similar</li> 395<li>set the URL field to an upstream bug or similar</li>
405<li>search for reserved or assigned CVE identifier and add it to the bug title, request a CVE otherwise</li> 396<li>search for a reserved or assigned CVE identifier and add it to the bug title,
406<li>optionally assign a GLSA coordinator for the bug, by adding the 397 request a CVE otherwise</li>
407 coordinator name to the status whiteboard</li> 398<li>enter the bug number in the CVE tracker (given the wrangler has access to it)</li>
399<li>set the Alias field to the CVE identifier.
400 In case there are multiple identifiers, use the first one.</li>
408</ul> 401</ul>
409 402
410<warn> 403<warn>
411You should not change bug severity once it has been assigned. If you want to 404You should not change bug severity once it has been assigned. If you want to
412increase developer awareness that a bug needs care, use the Priority field 405increase developer awareness that a bug needs care, use the Priority field
413instead. 406instead.
414</warn> 407</warn>
415 408
416</body> 409</body>
417</section> 410</section>
418<section> 411<section>
419<title>Timeframe and backup procedures</title> 412<title>Timeframe and backup procedures</title>
420<body> 413<body>
421 414
422<p> 415<p>
… …
439<body> 432<body>
440 433
441<p> 434<p>
442The GLSA coordinator has responsibility for the following tasks: 435The GLSA coordinator has responsibility for the following tasks:
443</p> 436</p>
444 437
445<ul> 438<ul>
446<li>determine what must be done in order to close the vulnerability (for 439<li>determine what must be done in order to close the vulnerability (for
447 example identify the upstream version containing the fix)</li> 440 example identify the upstream version containing the fix)</li>
448<li>if no fix is available from upstream yet, ensure that the bug is correctly 441<li>if no fix is available from upstream yet, ensure that the bug is correctly
449 reported to the upstream developer and set status whiteboard to 442 reported to the upstream developer and set status whiteboard to
450 <c>upstream</c></li> 443 <c>upstream</c></li>
451<li>if a fix is available, get the package maintainer involved to produce and 444<li>if a fix is available, get the package maintainer involved to produce and
452 commit an ebuild containing the fix and set status whiteboard to <c>ebuild</c></li> 445 commit an ebuild containing the fix and set status whiteboard to <c>ebuild</c></li>
453<li>once an ebuild is committed, evaluate what keywords are needed for the fix 446<li>once an ebuild is committed, evaluate what keywords are needed for the fix
454 ebuild and get arch-specific teams to test and mark 447 ebuild and get arch-specific Teams to test and mark
455 the ebuild stable on their architectures (arch-teams should be cc'd on 448 the ebuild stable on their architectures (arch teams should be cc'd on
456 the bug, as well as releng during release preparation) and set status 449 the bug, as well as releng during release preparation) and set status
457 whiteboard to <c>stable</c></li> 450 whiteboard to <c>stable</c></li>
458<li>arch-maintainers should mark the ebuild stable if there is no regression 451<li>arch-maintainers should mark the ebuild stable if there is no regression
459 in the fix ebuild compared to the latest vulnerable version</li> 452 in the fix ebuild compared to the latest vulnerable version</li>
460<li>in parallel, writing a draft GLSA using the GLSAMaker tool</li> 453<li>in parallel, writing a draft GLSA using the GLSAMaker tool</li>
461<li>when the corrective ebuild is ready for all supported archs, set the 454<li>when the corrective ebuild is ready for all supported archs, set the
462 status whiteboard to <c>glsa</c></li> 455 status whiteboard to <c>glsa</c></li>
463</ul> 456</ul>
464 457
465<note> 458<note>
466If the bug makes progress and the assigned GLSA coordinator does not react, 459If the bug makes progress and the assigned GLSA coordinator does not react,
467the other members of the security team can help keeping the bug rolling by 460the other members of the Security Team can help keeping the bug rolling by
468updating its status. 461updating its status.
469</note> 462</note>
470 463
471</body> 464</body>
472</section> 465</section>
473<section> 466<section>
474<title>Timeframe and escalation procedures</title> 467<title>Timeframe and escalation procedures</title>
475<body> 468<body>
476 469
477<p> 470<p>
478In order to meet the target delay for vulnerability resolution, a number of 471In order to meet the target delay for vulnerability resolution, a number of
479escalation procedures have been defined. These include: 472escalation procedures have been defined. These include:
480</p> 473</p>
481 474
482<ul> 475<ul>
483<li>when a bug in a waiting state needs urgent care, 476<li>when a bug in a waiting state needs urgent care,
484 you should change the status whiteboard 477 you should change the status whiteboard
485 entries to their "+" counterpart: <c>upstream+</c>, <c>ebuild+</c>, 478 entries to their "+" counterpart: <c>upstream+</c>, <c>ebuild+</c>,
486 <c>stable+</c> and <c>glsa+</c></li> 479 <c>stable+</c> and <c>glsa+</c></li>
487<li>if no upstream fix is available (<c>upstream+</c> status), a decision must 480<li>if no upstream fix is available (<c>upstream+</c> status), a decision must
488 be taken on masking the 481 be taken on masking the
489 package: the security team can mask a package which is not depended on by 482 package: The Security Team can mask a package which is not depended on by
490 itself, but need a TLP manager approval before masking a package which is 483 itself, maintainers should be consulted before masking a package which is
491 not standalone</li> 484 not standalone</li>
492<li>if the maintainer/herd does not show up for producing the ebuild during 48 485<li>if the maintainer/herd does not show up for producing the ebuild during 48
493 hours after summoning (<c>ebuild+</c> status), the security team should 486 hours after summoning (<c>ebuild+</c> status), the Security Team should
494 try to bump the ebuild by itself</li> 487 try to bump the ebuild by itself</li>
495<li>if testing and marking stable takes too much time (<c>stable+</c> status), 488<li>if testing and marking stable takes too much time (<c>stable+</c> status),
496 the security team will shout on IRC channels and gentoo-dev list to get 489 the Security Team will shout on IRC channels and gentoo-dev list to get
497 more testers. It will either mark the ebuild stable by itself or, in the 490 more testers. It will either mark the ebuild stable by itself or, in the
498 event this cannot be done due to stability issues, mask it (see security 491 event this cannot be done due to stability issues, mask it (see security
499 masking approval policy above)</li> 492 masking approval policy above)</li>
500<li>if the GLSA coordinator does not show up to draft a GLSA (<c>glsa+</c> 493<li>if the GLSA coordinator does not show up to draft a GLSA (<c>glsa+</c>
501 status), then another member of the security team should draft the GLSA 494 status), then another member of the Security Team should draft the GLSA
502 and submit it to peer review</li> 495 and submit it to peer review</li>
503</ul> 496</ul>
504 497
505</body> 498</body>
506</section> 499</section>
507<section> 500<section>
508<title>Good practices for security bugs</title> 501<title>Good practices for security bugs</title>
509<body> 502<body>
510 503
511<p> 504<p>
512Security bugs differ from other bugs, in that an easy and simple upgrade path 505Security bugs differ from other bugs, in that an easy and simple upgrade path
513must be presented to users through the GLSA. Therefore package maintainers and 506must be presented to users through the GLSA. Therefore package maintainers and
514GLSA coordinators should follow these good practices: 507GLSA coordinators should follow these good practices:
515</p> 508</p>
516 509
… …
522 than any previously published version, so that an easy upgrade path can 515 than any previously published version, so that an easy upgrade path can
523 be proposed to the user</li> 516 be proposed to the user</li>
524<li>In case of a patch, it should only be applied to the more recent version, 517<li>In case of a patch, it should only be applied to the more recent version,
525 there is no need to rev-bump all ebuilds with a patched version</li> 518 there is no need to rev-bump all ebuilds with a patched version</li>
526<li>Vulnerable versions should be left in the tree until the bug enters the 519<li>Vulnerable versions should be left in the tree until the bug enters the
527 <c>stable</c> status, in order to correctly evaluate what keywords 520 <c>stable</c> status, in order to correctly evaluate what keywords
528 are needed for the fix version</li> 521 are needed for the fix version</li>
529</ul> 522</ul>
530 523
531</body> 524</body>
532</section> 525</section>
533<section> 526<section>
534<title>Temporary GLSAs</title> 527<title>Temporary GLSAs</title>
535<body> 528<body>
536 529
530<note>
531This is no longer common practice.
532</note>
533
537<p> 534<p>
538If a <e>blocker</e> or <e>critical</e> or <e>major</e> vulnerability cannot 535If a <e>blocker</e> or <e>critical</e> or <e>major</e> vulnerability cannot
539totally be corrected in the target delay, 536totally be corrected in the target delay,
540an early warning GLSA should be written with workaround information. 537an early warning GLSA should be written with workaround information.
541This GLSA will be replaced by the final GLSA when the 538This GLSA will be replaced by the final GLSA when the
542definitive correction is available. 539definitive correction is available.
543</p> 540</p>
544 541
545<p> 542<p>
546If a common (type A or B) package is masked for security reasons, a temporary 543If a common (type A or B) package is masked for security reasons, a temporary
547GLSA should be issued to explain why the package is currently unavailable 544GLSA should be issued to explain why the package is currently unavailable
548and/or why people should uninstall the current version. This GLSA will be 545and/or why people should uninstall the current version. This GLSA will be
549replaced by the final GLSA when the fix becomes available and the package is 546replaced by the final GLSA when the fix becomes available and the package is
550unmasked. 547unmasked.
551</p> 548</p>
552 549
553</body> 550</body>
554</section> 551</section>
555</chapter> 552</chapter>
556 553
557<chapter> 554<chapter>
558<title>GLSA publication process</title> 555<title>GLSA publication process</title>
559<section> 556<section>
560<title>Peer review</title> 557<title>Peer review</title>
561<body> 558<body>
562 559
563<p> 560<p>
564Once ready, a GLSA should be submitted to peer review. At least two members 561Once ready, a GLSA should be submitted to peer review. At least two members
565of the security team must approve the draft GLSA. Once the draft passes the 562of the Security Team must approve the draft GLSA. Once the draft passes the
566peer review process, it should be assigned an official GLSA number. 563peer review process, it should be assigned an official GLSA number.
567</p> 564</p>
568 565
569</body> 566</body>
570</section> 567</section>
571<section> 568<section>
572<title>GLSA release</title> 569<title>GLSA release</title>
573<body> 570<body>
574 571
575<p> 572<p>
576Once the GLSA passes the peer review process (and after making sure the ebuild 573Once the GLSA passes the peer review process (and after making sure the ebuild
577has made its way into the stable tree), the GLSA coordinator should 574has made its way into the stable tree), the GLSA coordinator should
578commit the GLSA XML in the Gentoo CVS repository. 575commit the GLSA XML in the Gentoo CVS repository.
579Once this is done, the GLSA will automatically appear on the 576Once this is done, the GLSA will automatically appear on the
580<uri link="http://glsa.gentoo.org">official GLSA index page</uri> and 577<uri link="http://glsa.gentoo.org">official GLSA index page</uri> and
… …
588<body> 585<body>
589 586
590<p> 587<p>
591The GLSA text version must be published by the GLSA coordinator to the 588The GLSA text version must be published by the GLSA coordinator to the
592following media: 589following media:
593</p> 590</p>
594 591
595<table> 592<table>
596<tr> 593<tr>
597 <ti>Gentoo Linux official announcement mailing-list</ti> 594 <ti>Gentoo Linux official announcement mailing-list</ti>
598 <ti> 595 <ti>
599 <mail link="gentoo-announce@lists.gentoo.org">gentoo-announce@lists.gentoo.org</mail> 596 <mail link="gentoo-announce@lists.gentoo.org">gentoo-announce@lists.gentoo.org</mail>
600 </ti> 597 </ti>
601</tr> 598</tr>
602<tr> 599<tr>
603 <ti>Bugtraq security mailing-list</ti>
604 <ti>
605 <mail link="bugtraq@securityfocus.com">bugtraq@securityfocus.com</mail>
606 </ti>
607</tr>
608<tr>
609 <ti>Full-disclosure security mailing-list</ti>
610 <ti>
611 <mail link="full-disclosure@lists.grok.org.uk">
612 full-disclosure@lists.grok.org.uk
613 </mail>
614 </ti>
615</tr>
616<tr>
617 <ti>Linuxsecurity.com advisories service</ti>
618 <ti>
619 <mail link="security-alerts@linuxsecurity.com">
620 security-alerts@linuxsecurity.com
621 </mail>
622 </ti>
623</tr>
624<tr>
625 <ti>Gentoo Linux announcement forum</ti> 600 <ti>Gentoo Linux announcement forum</ti>
626 <ti><uri>http://forums.gentoo.org/viewforum.php?f=16</uri></ti> 601 <ti><uri>http://forums.gentoo.org/viewforum.php?f=16</uri></ti>
627</tr> 602</tr>
628</table> 603</table>
629 604
630<p> 605<p>
631There should be one single email sent, with the following rules: 606There should be one single email sent, with the following rules:
632</p> 607</p>
633 608
634<ul> 609<ul>
635<li>The <c>To:</c> field must be set to gentoo-announce</li> 610<li>The <c>To:</c> field must be set to gentoo-announce</li>
636<li>The <c>Cc:</c> filed must contain the other email addresses</li>
637<li>The <c>From:</c> and <c>Return-Path:</c> must be set to the GLSA 611<li>The <c>From:</c> and <c>Return-Path:</c> must be set to the GLSA
638 coordinator @gentoo.org address</li> 612 coordinator @gentoo.org address</li>
639<li>The <c>Subject:</c> field must be "[ GLSA XXXXYY-ZZ ] Your vulnerability 613<li>The <c>Subject:</c> field must be "[ GLSA XXXXYY-ZZ ] Your vulnerability
640 here"</li> 614 here"</li>
641<li>The body should only contain the text version of the GLSA</li> 615<li>The body should only contain the text version of the GLSA</li>
642<li>The email must be signed by the GLSA coordinator GPG key</li> 616<li>The email must be signed by the GLSA coordinator GPG key</li>
643</ul> 617</ul>
644 618
645<note> 619<note>
646Developer key IDs can be found on the Gentoo Linux 620Developer key IDs can be found on the Gentoo Linux
647<uri link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml"> 621<uri link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">
648Developer list</uri>. All the security team GPG keys are published on public 622Developer list</uri>. All the Security Team GPG keys are published on public
649key servers, including (but not limited to) 623key servers, including (but not limited to)
650<uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri>. 624<uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri>.
651</note> 625</note>
652 626
653<note> 627<note>
654To minimize errors in the publication process, the forum publication step is 628To minimize errors in the publication process, the forum publication step is
655handled by an automatic poster when it receives the announcement. 629handled by an automatic poster when it receives the announcement.
656</note> 630</note>
657 631
632<note>
633Starting Feb 2, 2012, we have decied to no longer CC any third parties.
634The gentoo-announce mailing list has little other traffic, so that they
635should be subscribed there. General security mailing lists such as full-
636disclosure or bugtraq are not our target audience, and having various
637distributions send notices about the same issues is not of any use to most
638readers there, they too should be on gentoo-announce.
639</note>
640
658<p> 641<p>
659When the GLSA has been published the corresponding bugzilla bug should be 642When the GLSA has been published the corresponding bugzilla bug should be
660resolved as FIXED, with the GLSA number referenced in the comments section 643resolved as FIXED, with the GLSA number referenced in the comments section
661of the bug. 644of the bug. GLSAMaker 2 offers this option after releasing the advisory.
662</p> 645</p>
663 646
664</body> 647</body>
665</section> 648</section>
666<section> 649<section>
667<title>GLSA errata</title> 650<title>GLSA errata</title>
668<body> 651<body>
669 652
670<p> 653<p>
671Sometimes an error will slip through the peer-review process and an incorrect 654Sometimes an error will slip through the peer-review process and an incorrect
672GLSA will be published to the world. Depending on the severity of the error(s), 655GLSA will be published to the world. Depending on the severity of the error(s),
673the following policy for erratum should be applied: 656the following policy for erratum should be applied:
674</p> 657</p>
675 658
676<table> 659<table>
… …
700 <ti>Error in affected/unaffected versions number, but people using stable 683 <ti>Error in affected/unaffected versions number, but people using stable
701 packages and applying GLSA instructions are protected anyway</ti> 684 packages and applying GLSA instructions are protected anyway</ti>
702 <ti>The GLSA XML should be corrected, no publication</ti> 685 <ti>The GLSA XML should be corrected, no publication</ti>
703</tr> 686</tr>
704<tr> 687<tr>
705 <ti>Error in affected/unaffected versions number, people applying GLSA 688 <ti>Error in affected/unaffected versions number, people applying GLSA
706 instructions are not at all protected</ti> 689 instructions are not at all protected</ti>
707 <ti>An erratum GLSA should be published, replacing the erroneous one</ti> 690 <ti>An erratum GLSA should be published, replacing the erroneous one</ti>
708</tr> 691</tr>
709</table> 692</table>
710 693
711</body> 694</body>
712</section> 695</section>
713</chapter> 696</chapter>
714</guide> 697</guide>
698<!-- vim: set et noai inde=: -->
Legend:
Removed from v.1.21  
changed lines
  Added in v.1.24
  ViewVC Help
Powered by ViewVC 1.1.20