/[gentoo]/xml/htdocs/security/en/coordinator_guide.xml
Gentoo

Diff of /xml/htdocs/security/en/coordinator_guide.xml

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

Revision 1.25 Revision 1.26
2<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> 2<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
3<guide link="/security/en/coordinator_guide.xml"> 3<guide link="/security/en/coordinator_guide.xml">
4<title>GLSA Coordinator Guide</title> 4<title>GLSA Coordinator Guide</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 contains procedures, tips and tricks applying to the 22This document contains procedures, tips and tricks applying to the
20GLSA Coordinator job. 23GLSA Coordinator job.
21</abstract> 24</abstract>
22 25
23<!-- The content of this document is licensed under the CC-BY-SA license --> 26<!-- The content of this document is licensed under the CC-BY-SA license -->
24<!-- See http://creativecommons.org/licenses/by-sa/1.0 --> 27<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
25<license/> 28<license/>
26 29
27<version>0.8.8</version> 30<version>0.9</version>
28<date>2008-05-09</date> 31<date>2011-05-15</date>
29 32
30<chapter> 33<chapter>
31<title>Prerequisites</title> 34<title>Prerequisites</title>
32<section> 35<section>
33<title>Accounts</title> 36<title>Accounts</title>
34<body> 37<body>
35 38
36<p> 39<p>
37A certain number of accounts must be established before working as a GLSA 40A certain number of accounts must be established before working as a GLSA
38coordinator. To draft GLSAs you must get a 41coordinator. To draft GLSAs you must get a
39<uri link="https://glsamaker.gentoo.org:4433/">GLSAMaker</uri> account. To 42<uri link="https://glsamaker.gentoo.org:4433/">GLSAMaker</uri> account. To
40manage security bugs you need to have a 43manage security bugs you need to have a
41<uri link="https://bugs.gentoo.org">Bugzilla</uri> account, which will be 44<uri link="https://bugs.gentoo.org">Bugzilla</uri> account, which will be
42upgraded to <c>editbugs</c> privileges. To send GLSA announcements you 45upgraded to <c>editbugs</c> privileges. To send GLSA announcements you
43need to have a yourname@gentoo.org address (i.e. to be a Gentoo developer). 46need to have a yourname@gentoo.org address (i.e. to be a Gentoo developer).
153<p> 156<p>
154Vulnerabilities are security bugs in the upstream software or introduced in 157Vulnerabilities are security bugs in the upstream software or introduced in
155the Gentoo ebuild packaging. These bugs result in GLSAs. Kernel bugs have 158the Gentoo ebuild packaging. These bugs result in GLSAs. Kernel bugs have
156their own category and should not filed as <c>Vulnerability</c>. 159their own category and should not filed as <c>Vulnerability</c>.
157</p> 160</p>
158 161
159</body> 162</body>
160</section> 163</section>
161<section> 164<section>
162<title>Kernel</title> 165<title>Kernel</title>
163<body> 166<body>
164 167
165<p> 168<p>
166Kernel vulnerabilities are treated using a separate procedure. To easily 169Kernel vulnerabilities are treated using a separate procedure. To easily
167distinguish them from the other bugs, they are filed under the <c>Kernel</c> 170distinguish them from the other bugs, they are filed under the <c>Kernel</c>
168category. Kernel bugs do not result in GLSAs but have their own publication 171category. Kernel bugs do not result in GLSAs.
169system (Gentoo KISS).
170</p> 172</p>
171 173
172</body> 174</body>
173</section> 175</section>
174<section> 176<section>
175<title>Default config</title> 177<title>Default config</title>
176<body> 178<body>
177 179
178<p> 180<p>
179Gentoo packages should be as secure by default as possible. Default 181Gentoo packages should be as secure by default as possible. Default
180configuration bugs are filed when the default configuration shipped with the 182configuration bugs are filed when the default configuration shipped with the
181package can be improved in terms of security. <c>Default config</c> bugs do 183package can be improved in terms of security. <c>Default config</c> bugs do
182not generate GLSAs. 184not generate GLSAs.
183</p> 185</p>
184 186
195component. When the finding has been verified they are switched to 197component. When the finding has been verified they are switched to
196<c>Vulnerability</c>. 198<c>Vulnerability</c>.
197</p> 199</p>
198 200
199</body> 201</body>
200</section> 202</section>
201<section> 203<section>
202<title>Restricted bugs</title> 204<title>Restricted bugs</title>
203<body> 205<body>
204 206
205<p> 207<p>
206Sometimes a bug is communicated to us under the promise we'll keep it secret 208Sometimes a bug is communicated to us under the promise we'll keep it secret
207until a public release, usually known as the embargo date or coordinated release date. 209until a public release, usually known as the embargo date or coordinated release date.
208Restricted bugs have the "Gentoo Security" checkbox 210Restricted bugs have the "Gentoo Security" checkbox
209checked and therefore can only be accessed by Gentoo Security Team members. 211checked and therefore can only be accessed by Gentoo Security Team members.
210External people (package maintainer, arch testers, Release Engineering) may be 212External people (package maintainers, arch testers) may be
211added on a per-name basis, aliases should never be used (because they are too 213added on a per-name basis, aliases should never be used (because they are too
212wide and won't allow bug comments). 214wide and won't allow bug comments).
213</p> 215</p>
214 216
215<p> 217<p>
216There are three different types of restricted bugs. The first (and most secret) 218There are three different types of restricted bugs. The first (and most secret)
217ones are the <c>CLASSIFIED</c> bugs. A bug is classified when it contains 219ones are the <c>CLASSIFIED</c> bugs. A bug is classified when it contains
218information that should never be released. This includes quotes of personal 220information that should never be released. This includes quotes of personal
219emails sent to restricted mailing-lists or non-public intermediary patches. 221emails sent to restricted mailing-lists or non-public intermediary patches.
220Classified bugs are identified by the <c>CLASSIFIED</c> keyword in their Status 222Classified bugs are identified by the <c>CLASSIFIED</c> keyword in their Status
221Whiteboard. Once CLASSIFIED, a bug cannot go back to unclassified status unless 223Whiteboard. Once CLASSIFIED, a bug cannot go back to unclassified status unless
222at least two security managers agree to declassify it. 224at least two security managers agree to declassify it.
223<c>CLASSIFIED</c> bugs should never be opened (unrestricted). 225<c>CLASSIFIED</c> bugs should never be opened (unrestricted).
224</p> 226</p>
225 227
257<tr> 259<tr>
258<th>Element</th> 260<th>Element</th>
259<th>Content</th> 261<th>Content</th>
260<th>Example</th> 262<th>Example</th>
261</tr> 263</tr>
262<tr> 264<tr>
263<ti>RATING</ti> 265<ti>RATING</ti>
264<ti>The vulnerability rating, following current policy rules</ti> 266<ti>The vulnerability rating, following current policy rules</ti>
265<ti>B3</ti> 267<ti>B3</ti>
266</tr> 268</tr>
267<tr> 269<tr>
268<ti>[status]</ti> 270<ti>[status]</ti>
269<ti>The bug status, with optional extra information</ti> 271<ti>The bug status, with optional extra information</ti>
270<ti>[ebuild+]</ti> 272<ti>[ebuild+]</ti>
271</tr> 273</tr>
272<tr>
273<ti>coordinator</ti>
274<ti>The nickname of the coordinator assigned to the bug, optional</ti>
275<ti>koon</ti>
276</tr>
277</table> 274</table>
278 275
279<p> 276<p>
280The following statuses are accepted: 277The following statuses are accepted:
281</p> 278</p>
282 279
283<table> 280<table>
284<tr> 281<tr>
285<th>Status</th> 282<th>Status</th>
286<th>Description</th> 283<th>Description</th>
287</tr> 284</tr>
288<tr> 285<tr>
289<ti>upstream</ti> 286<ti>upstream</ti>
290<ti>Waiting for upstream developer to publish a new version or patch</ti> 287<ti>Waiting for upstream developer to publish a new version or patch</ti>
291</tr> 288</tr>
308<tr> 305<tr>
309<ti>stable+</ti> 306<ti>stable+</ti>
310<ti>Some arches are taking too long to mark the package appropriately</ti> 307<ti>Some arches are taking too long to mark the package appropriately</ti>
311</tr> 308</tr>
312<tr> 309<tr>
313<ti>glsa?</ti> 310<ti>glsa?</ti>
314<ti>Security must make a decision on whether a GLSA is needed</ti> 311<ti>Security must make a decision on whether a GLSA is needed</ti>
315</tr> 312</tr>
316<tr> 313<tr>
317<ti>glsa</ti> 314<ti>glsa</ti>
318<ti>Waiting for the coordinator to send his GLSA</ti> 315<ti>Waiting for the coordinator to send his GLSA</ti>
319</tr> 316</tr>
320<tr> 317<tr>
321<ti>glsa+</ti> 318<ti>glsa+</ti>
322<ti>The GLSA is late, any GLSA coordinator can correct and send it</ti> 319<ti>The GLSA is late, any GLSA coordinator can correct and send it</ti>
320</tr>
321<tr>
322<ti>cleanup</ti>
323<ti>Waiting for the Gentoo package maintainer to remove vulnerable ebuilds from the tree</ti>
324</tr>
325<tr>
326<ti>cleanup+</ti>
327<ti>No response from the maintainer, the Security Team should remove vulnerable ebuilds as needed</ti>
323</tr> 328</tr>
324</table> 329</table>
325 330
326<p> 331<p>
327The following extra information is admitted: 332The following extra information is admitted:
328</p> 333</p>
329 334
330<table> 335<table>
331<tr> 336<tr>
332<th>Extra information</th> 337<th>Extra information</th>
333<th>Description</th> 338<th>Description</th>
334<th>Corresponding statuses</th> 339<th>Corresponding statuses</th>
335</tr> 340</tr>
336<tr> 341<tr>
337<ti>tomask</ti> 342<ti>tomask</ti>
338<ti>When a package.mask has been requested against the package</ti> 343<ti>When a package.mask has been requested against the package</ti>
339<ti>upstream+, ebuild+</ti> 344<ti>upstream+, ebuild+</ti>
340</tr> 345</tr>
341<tr> 346<tr>
342<ti>masked</ti> 347<ti>masked</ti>
343<ti>if the package was masked as a temporary solution</ti> 348<ti>if the package was masked as a temporary solution</ti>
344<ti>upstream+, ebuild+</ti> 349<ti>upstream+, ebuild+</ti>
345</tr> 350</tr>
346<tr> 351<tr>
347<ti>Arch names</ti>
348<ti>When only one or two supported arches are blocking the bug</ti>
349<ti>stable+</ti>
350</tr>
351<tr>
352<ti>tempglsa</ti> 352<ti>tempglsa</ti>
353<ti>When a temporary GLSA was issued as a temporary solution</ti> 353<ti>When a temporary GLSA was issued as a temporary solution</ti>
354<ti>upstream+, ebuild+</ti> 354<ti>upstream+, ebuild+</ti>
355</tr> 355</tr>
356<tr> 356<tr>
357<ti>blocked</ti> 357<ti>blocked</ti>
358<ti>When the bug is blocked by another bug</ti> 358<ti>When the bug is blocked by another bug</ti>
359<ti>(any)</ti> 359<ti>(any)</ti>
360</tr> 360</tr>
361</table> 361</table>
362 362
363<p> 363<p>
364Examples: 364Examples:
365</p> 365</p>
366 366
367<table> 367<table>
368<tr> 368<tr>
369<ti>C0 [stable]</ti> 369<ti>C0 [stable]</ti>
370</tr> 370</tr>
371<tr> 371<tr>
372<ti>A3 [ebuild] jaervosz</ti> 372<ti>B1 [stable blocked]</ti>
373</tr>
374<tr>
375<ti>B1 [stable+ amd64] koon</ti>
376</tr> 373</tr>
377</table> 374</table>
378 375
379</body> 376</body>
380</section> 377</section>
381<section> 378<section>
382<title>Determining original bug status</title> 379<title>Determining original bug status</title>
383<body> 380<body>
384 381
385<p> 382<p>
386When the fix is not available from the upstream developer and/or there is 383When the fix is not available from the upstream developer and/or there is
387no official patch to solve the problem, the bug is in [upstream] status. If 384no official patch to solve the problem, the bug is in <c>[upstream]</c> status.
388the solution must be found amongst Gentoo developers, the bug is in [inhouse]
389status. If a fix is available, the bug is in [ebuild] status. 385If a fix is available, the bug is in <c>[ebuild]</c> status.
390If a fix ebuild is put 386If a fixed ebuild is put in the Portage tree, the next step is stabilizing, so
391in the portage tree, the bug is in [stable] status. When the fix ebuild is 387the bug is in <c>[stable]</c> status.
392in portage with all required keywords set, the bug is in [glsa] status. 388When the fixed ebuild is in Portage with all required keywords set and if the
389issue is severe enough to warrant a GLSA, the bug is in <c>[glsa]</c> status.
390Is the bug not severe enough, GLSA voting is next, so the status would be
391<c>[glsa?]</c>.
393</p> 392</p>
394 393
395</body> 394</body>
396</section> 395</section>
397<section> 396<section>
398<title>Bugs in [upstream] status</title> 397<title>Bugs in [upstream] status</title>
399<body> 398<body>
400 399
401<p> 400<p>
402In [upstream] status, we wait for the fix version or a decent patch to 401In <c>[upstream]</c> status, we wait for the fixed version or a decent patch to
403appear. This status requires to regularly check upstream for information: 402appear. This status requires to regularly check upstream for information:
404development and announce mailing lists, websites, Bugs database, CVS when 403development and announce mailing lists, websites, bugs database, VCS when
405available, are all relevant sources of information. Unofficial patches must 404available, are all other relevant sources of information. Unofficial patches
406be taken into account only if the upstream developer does not react to the 405must be taken into account only if the upstream developer does not react to the
407vulnerability, and they must be thoroughly double-checked to ensure they 406vulnerability, and they must be thoroughly double-checked to ensure they
408are not evil. When a fix version is announced or a patch is found, the bug 407are not evil. When a fix version is announced or a patch is found, the bug
409enters [ebuild] status. 408enters <c>[ebuild]</c> status.
410</p>
411
412<p> 409</p>
410
411<p>
413If there is no reaction from upstream and no patch, we enter [upstream+] 412If there is no reaction from upstream and no patch, we enter <c>[upstream+]</c>
414status. The only option here is to security-mask the vulnerable package 413status. The only option here is to security-mask the vulnerable package
415and issue a temporary GLSA if needed. See the policy for more details on the 414and issue a temporary GLSA if needed. See the policy for more details on the
416security masking approval procedure. The status whiteboard should then be 415security masking approval procedure. The status whiteboard should then be
417flagged with masked and/or tempglsa keywords and bug severity set to 416flagged with masked and/or tempglsa keywords and bug severity set to
418<c>enhancement</c>. 417<c>enhancement</c>.
419</p> 418</p>
420 419
421</body> 420</body>
422</section> 421</section>
423<section> 422<section>
424<title>Bugs in [ebuild] status</title> 423<title>Bugs in [ebuild] status</title>
425<body> 424<body>
426 425
427<p> 426<p>
428In [ebuild] status, we must identify the maintainer of the package, and 427In <c>[ebuild]</c> status, we must identify the maintainer of the package, and
429summon him to commit a fix ebuild. Sources to identify the herd or developer 428summon him to commit a fixed ebuild. Sources to identify the herd or developer
430responsible for maintaining a package are the metadata.xml file in the 429responsible for maintaining a package are the metadata.xml file in the
431directory of the package in portage and the Changelog file showing who did the 430directory of the package in portage and the Changelog file showing who did the
432latest version bumps. You should Cc: the herd and/or maintainer responsible 431latest version bumps. You should Cc: the herd and maintainer responsible
433for the package on the bug and ask him to provide an ebuild for the fix 432for the package on the bug and ask him to provide an ebuild for the fixed
434version. You should periodically check that an ebuild wasn't committed 433version. You should periodically check that an ebuild wasn't committed
435to portage without any comment on the bug (it happens). When the ebuild 434to Portage without any comment on the bug (it happens). When the ebuild
436appears, the bug enters [stable] status. 435appears, the bug enters <c>[stable]</c> status.
437</p>
438
439<p> 436</p>
437
438<p>
440If the maintainer doesn't show up, we enter [ebuild+] status. In case a fixed 439If the maintainer doesn't show up, we enter <c>[ebuild+]</c> status. In case a
441version is available, you should test if a simple version bump (renaming the 440fixed version is available, you should test if a simple version bump (renaming
442ebuild to the version and emerging it) works. If only a patch is available, you 441the ebuild to the needed/fixed version and emerging it) works.
443should test if it applies cleanly. Then you should find a security bug wrangler 442If only a patch is available, you should test if it applies cleanly.
444with x86 commit rights to do the bump and mark the ebuild ~ for testing. 443Then you should find a Security Team member with Portage tree commit rights to
444do the bump and mark the ebuild <c>~</c> for testing.
445</p> 445</p>
446 446
447<p> 447<p>
448If the bump is not easy and/or any problem is detected with the bumped ebuild, 448If the bump is not easy and/or any problem is detected with the bumped ebuild,
449the only option is to security-mask the unmaintained package and issue a 449the only option is to security-mask the unmaintained package and issue a
450temporary GLSA if needed. See the policy for more details on the 450temporary GLSA if needed. See the policy for more details on the
451security masking approval procedure. The status whiteboard should then be 451security masking approval procedure. The status whiteboard should then be
452flagged with masked and/or tempglsa keywords and bug severity set to 452flagged with <c>masked</c> and/or <c>tempglsa</c> keywords and bug severity set to
453<c>enhancement</c>. 453<c>enhancement</c>.
454</p> 454</p>
455 455
456</body> 456</body>
457</section> 457</section>
458<section> 458<section>
459<title>Bugs in [stable] status</title> 459<title>Bugs in [stable] status</title>
460<body> 460<body>
461 461
462<p> 462<p>
463In [stable] status, you have to determine what KEYWORDS the provided ebuild 463In <c>[stable]</c> status, you have to determine what KEYWORDS the provided
464needs before the GLSA can go out. This can be tricky. You have to consider 464ebuild needs before the GLSA can go out. This can be tricky.
465every version currently in portage so that the fix ebuild has <e>equally or 465You have to consider every version currently in portage so that the fix
466more stable</e> keywords than any other packages in portage. Here is an 466ebuild has <e>equally or more stable</e> keywords than any other packages
467example: 467in Portage. Here is an example:
468</p> 468</p>
469 469
470<table> 470<table>
471<tr> 471<tr>
472<th>Versions</th> 472<th>Versions</th>
473<th>Keywords</th> 473<th>Keywords</th>
474</tr> 474</tr>
475<tr> 475<tr>
476<ti>Affected</ti> 476<ti>Affected</ti>
477<ti>x86 ~ppc ~ia64</ti> 477<ti>x86 ~ppc ~ia64</ti>
478</tr> 478</tr>
479<tr> 479<tr>
480<ti>Affected</ti> 480<ti>Affected</ti>
481<ti>x86 ppc</ti> 481<ti>x86 ppc</ti>
482</tr> 482</tr>
483<tr> 483<tr>
484<ti>Affected</ti> 484<ti>Affected</ti>
485<ti>~x86 ~ppc ~ia64</ti> 485<ti>~x86 ~ppc ~ia64</ti>
486</tr> 486</tr>
487<tr> 487<tr>
488<ti>Fix must have:</ti> 488<ti>Fix must have:</ti>
489<th>x86 ppc ~ia64</th> 489<th>x86 ppc ~ia64</th>
490</tr> 490</tr>
491</table> 491</table>
492 492
493<note> 493<note>
494You can use <uri>http://packages.gentoo.org</uri> to help you determine 494You can use <uri>http://packages.gentoo.org</uri> to help you determine
495the needed KEYWORDS. If affected packages were removed by the package 495the needed KEYWORDS. If affected packages were removed by the package
496maintainer too early, you should use the 496maintainer too early, you should use our
497<uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/">CVS access</uri> 497<uri link="http://sources.gentoo.org/cgi-bin/viewvc.cgi">ViewVC</uri>
498to dig in the Attic and look for old KEYWORDS. 498to dig in the Attic and look for old KEYWORDS.
499</note> 499</note>
500 500
501<p> 501<p>
502Once determined (and noted for reference on the bug) the needed KEYWORDS, 502Once you have determined (and noted for reference on the bug) the needed KEYWORDS,
503you should Cc: arch teams and ask them to mark the ebuild stable or ~ 503you should Cc: arch teams and ask them to mark the ebuild stable or testing
504accordingly. To make sure that the arch teams will pick the bug up, don't forget 504accordingly. To make sure that the arch teams will pick the bug up, don't forget
505to add "STABLEREQ" to the bug's "Keywords" field. The arches alias are 505to add "STABLEREQ" to the bug's "Keywords" field. The arches alias are
506archname@gentoo.org (x86@gentoo.org, ppc@gentoo.org...). All arches (including 506archname@gentoo.org (x86@gentoo.org, ppc@gentoo.org...). All arches (including
507"unsupported" arches) must be called. But note that only "supported" arches (as 507"unsupported" arches) must be called. But note that only "supported" arches (as
508defined in the policy) are needed before the bug can advance to [glsa] status 508defined in the policy) are needed before the bug can advance to <c>[glsa]</c> status
509You should periodically check for new keywords in the ebuild, as sometimes they 509You should periodically check for new keywords in the ebuild, as sometimes they
510are changed without a comment in the bug. As soon as the required KEYWORDS 510are changed without a comment in the bug. As soon as the required KEYWORDS
511are in the ebuild for all supported arches, the bug enters [glsa] status. 511are in the ebuild for all supported arches, the bug enters <c>[glsa]</c> status.
512</p>
513
514<p>
515During a release preparation period you should also Cc: Release Engineering
516(release@gentoo.org) on all bugs with [stable] status.
517</p> 512</p>
518 513
519<p> 514<p>
520If the arch teams take too much time testing and changing the KEYWORDS, or 515If the arch teams take too much time testing and changing the KEYWORDS, or
521they refuse to mark stable a package due to outstanding problems, the bug 516they refuse to mark stable a package due to outstanding problems, the bug
522enters [stable+] status. We must track down arch-maintainers to have them 517enters <c>[stable+]</c> status. We must track down arch maintainers to have them
523mark stable, help testing. You should also convince the arches that if they 518mark stable or help testing. You should also convince the arches that if they
524discover a bug in the ebuild that already was in previous "stable" versions, 519discover a bug in the ebuild that already was in previous "stable" versions,
525the ebuild should be marked "stable" anyway, even if it's not really stable, 520the ebuild should be marked "stable" anyway, even if it's not really stable,
526as specified in the policy. If the KEYWORDS can't be met, the only other 521as specified in the policy. If the KEYWORDS can't be met, the only other
527option is to security-mask the package: there is no acceptable unaffected 522option is to security-mask the package: there is no acceptable unaffected
528version, so it is like if no acceptable upstream fix was provided. 523version, so it is like if no acceptable upstream fix was provided.
529</p> 524</p>
530 525
531</body> 526</body>
532</section> 527</section>
533<section> 528<section>
534<title>Bugs in [glsa] status</title> 529<title>Bugs in [glsa] status</title>
535<body> 530<body>
536 531
537<p> 532<p>
538In [glsa] status, the security bug is corrected. We need to issue the GLSA 533In <c>[glsa]</c> status, the security bug is corrected. We need to issue the GLSA
539or close the bug without GLSA. The policy determines the cases where a GLSA 534or close the bug without GLSA. The policy determines the cases where a GLSA
540is needed and where a GLSA is not needed. There are also cases where a GLSA 535is needed and where a GLSA is not needed. There are also cases where a GLSA
541vote must take place to decide if a GLSA is needed ([glsa?] status). 536vote must take place to decide if a GLSA is needed (<c>[glsa?]</c> status).
542If at least two Security Team members vote for "no GLSA", then no GLSA should 537If at least two Security Team members vote for "no GLSA", then no GLSA should
543be issued. The bug remains in [glsa] status until a GLSA is published. 538be issued. The bug remains in <c>[glsa]</c> status until a GLSA is published.
544</p>
545
546<p> 539</p>
540
541<p>
547When a GLSA is needed but nothing was sent, the bug enters [glsa+] status. 542When a GLSA is needed but nothing was sent, the bug enters <c>[glsa+]</c> status.
548It's the case when the assigned GLSA coordinator did not draft and/or 543This is the case when there are delays during drafting, reviewing or sending
549made peer-reviewed and/or sent his GLSA. Other members of the Security Team 544the advisory. Any member of the Security Team should take the lead and finalize
550should take the lead at this point and finalize the GLSA. 545the GLSA.
546</p>
547
548</body>
549</section>
550<section>
551<title>Bugs in [cleanup] status</title>
552<body>
553
551</p> 554<p>
555This status is not in order like the others. It is used to denote that the
556maintainer needs to remove vulnerable ebuild versions in the tree.
557</p>
552 558
559<p>
560For example, the <e>foo</e> package has a vulnerability in versions earlier
561than 1.23. The version 1.24 was added to Portage and is stable already
562(i.e. the stabilization was done before the security impact of the release was
563known), only old ebuilds need to be removed. The next status in this case would
564be <c>[glsa]</c> or <c>[glsa?]</c> depending on severity.
565</p>
566
567<p>
568Another use case might be when a package was updated, and all steps are done
569(i.e. a GLSA was sent or the team decided against sending one), but the
570vulnerable ebuilds should really be removed to avoid users accidentally
571installing them, the bug could be left open and set to the <c>[cleanup]</c>
572state. This is usually not needed tough, but may be used on a case-to-case base
573when the Security Team has an elevated interest in vulnerable ebuilds
574getting removed for whatever reasons.
575</p>
553</body> 576</body>
554</section> 577</section>
555</chapter> 578</chapter>
556<chapter> 579<chapter>
557<title>Confidential vulnerability bug management</title> 580<title>Confidential vulnerability bug management</title>
558<section> 581<section>
559<title>Status whiteboard rules</title> 582<title>Status whiteboard rules</title>
560<body> 583<body>
561 584
562<p> 585<p>
563Confidential bugs should be following this pattern: "RATING [status] 586Confidential bugs should be following this pattern: <c>RATING [status]
564coordinator KEYWORD CRD", where: 587KEYWORD CRD</c>, where:
565</p> 588</p>
566 589
567<table> 590<table>
568<tr> 591<tr>
569<th>Element</th> 592<th>Element</th>
570<th>Content</th> 593<th>Content</th>
571<th>Example</th> 594<th>Example</th>
572</tr> 595</tr>
573<tr> 596<tr>
574<ti>RATING</ti> 597<ti>RATING</ti>
575<ti>The vulnerability rating, following current policy rules</ti> 598<ti>The vulnerability rating, following current policy rules</ti>
576<ti>B3</ti> 599<ti>B3</ti>
577</tr> 600</tr>
578<tr> 601<tr>
579<ti>[status]</ti> 602<ti>[status]</ti>
580<ti>The bug status, with optional extra information</ti> 603<ti>The bug status, with optional extra information</ti>
581<ti>[ebuild+]</ti> 604<ti>[ebuild+]</ti>
582</tr> 605</tr>
583<tr> 606<tr>
584<ti>coordinator</ti>
585<ti>The nickname of the coordinator assigned to the bug, optional</ti>
586<ti>koon</ti>
587</tr>
588<tr>
589<ti>KEYWORD</ti> 607<ti>KEYWORD</ti>
590<ti>The confidentiality level of the bug, can be CLASSIFIED, CONFIDENTIAL, SEMI-PUBLIC</ti> 608<ti>The confidentiality level of the bug, can be CLASSIFIED, CONFIDENTIAL, SEMI-PUBLIC</ti>
591<ti>CLASSIFIED</ti> 609<ti>CLASSIFIED</ti>
592</tr> 610</tr>
593<tr> 611<tr>
594<ti>CRD</ti> 612<ti>CRD</ti>
595<ti>The coordinated release date for the bugs disclosure. If no time is given, assume 14:00 UTC.</ti> 613<ti>The coordinated release date for the bugs disclosure. If no time is given, assume 14:00 UTC.</ti>
596<ti>2009-01-06 18:00 UTC</ti> 614<ti>2009-01-06 18:00 UTC</ti>
597</tr> 615</tr>
598 616
599</table> 617</table>
600 618
601<p> 619<p>
602The following extra statuses are accepted in confidential bugs: 620The following extra statuses are accepted in confidential bugs:
603</p> 621</p>
619</table> 637</table>
620 638
621</body> 639</body>
622</section> 640</section>
623<section> 641<section>
624<title>Handling confidential bugs</title> 642<title>Handling confidential bugs</title>
625<body> 643<body>
626 644
627<p> 645<p>
628Semi-public bugs should be handled as public bugs, except that no herd or arch 646Semi-public bugs should be handled as public bugs, except that no herd or arch
629alias should be Cc-ed on the bug but rather specific developers. 647alias should be Cc-ed on the bug but rather specific developers.
630</p> 648</p>
631 649
632<p> 650<p>
633Confidential and classified bugs need extra care. The ebuild and files fixing 651Confidential and classified bugs need extra care. The ebuild and files fixing
634the vulnerability should NOT be committed to portage CVS, and no part of those 652the vulnerability should NOT be committed to the Portage tree, and no part of
635bugs should ever be discussed in public. Patches or portage overlay tarballs 653those bugs should ever be discussed in public. Patches or Portage overlay
636can be attached to the bug, though. Testers will have to setup their own 654tarballs can be attached to the bug, though.
637overlay to test it. 655Testers will have to setup their own overlay to test it.
638The idea with those bugs is to prepare the ebuild and have it tested for the 656The idea with those bugs is to prepare the ebuild and have it tested for the
639coordinated release date, so that it can be released with all needed KEYWORDS 657coordinated release date, so that it can be released with all needed KEYWORDS
640together with the GLSA at the same time the issue goes public. 658together with the GLSA at the same time or shortly after the issue goes public.
641</p> 659</p>
642 660
643</body> 661</body>
644</section> 662</section>
645</chapter> 663</chapter>
646<chapter> 664<chapter>
647<title>GLSA drafting with GLSAMaker</title> 665<title>GLSA drafting with GLSAMaker</title>
648<section> 666<section>
649<title>General rules</title> 667<title>General rules</title>
650<body> 668<body>
651 669
652<p> 670<p>
653The GLSA should use the affected software name with proper capitalization, not 671The GLSA should use the affected software name with proper capitalization, not
654the Gentoo package name. For example, you should use "MySQL" and not "mysql". 672the Gentoo package name. For example, you should use "MySQL" and not "mysql".
655Lowercase names should be used only if the software has an all-lowercase name 673Lowercase names should be used only if the software has an all-lowercase name
1189<title>Security Subversion repository</title> 1207<title>Security Subversion repository</title>
1190<body> 1208<body>
1191 1209
1192<ul> 1210<ul>
1193<li>The <uri link="http://overlays.gentoo.org/proj/security/timeline">Security Subversion repository</uri> 1211<li>The <uri link="http://overlays.gentoo.org/proj/security/timeline">Security Subversion repository</uri>
1194contains several tools to collaboratively assess whether we are affected by new CVE identifiers, and 1212contains several tools to collaboratively assess whether we are affected by new CVE identifiers, and
1195tools to determine target keywords. Most tools directly interact with Bugzilla, making manual 1213tools to determine target keywords. Most tools directly interact with Bugzilla, making manual
1196copy-pasting unnecessary. 1214copy-pasting unnecessary.
1197</li> 1215</li>
1198</ul> 1216</ul>
1199 1217
1200</body> 1218</body>
1201</section> 1219</section>
1202</chapter> 1220</chapter>
1203</guide> 1221</guide>
1222<!-- vim: set et noai inde=: -->

Legend:
Removed from v.1.25  
changed lines
  Added in v.1.26

  ViewVC Help
Powered by ViewVC 1.1.20