1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
|
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/pl/vulnerability-policy.xml,v 1.9 2009/04/14 10:10:28 shadow Exp $ -->
<guide link="/security/pl/vulnerability-policy.xml" lang="pl">
<title>Zasady postępowania z błędami bezpieczeństwa w Gentoo</title>
<author title="Autor">
<mail link="koon@gentoo.org">Thierry Carrez</mail>
</author>
<author title="Autor">
<mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail>
</author>
<author title="Autor">
<mail link="vorlon@gentoo.org">Matthias Geerdsen</mail>
</author>
<author title="Autor">
<mail link="rbu@gentoo.org">Robert Buchholz</mail>
</author>
<author title="Tłumacz">
<mail link="shadow"/>
</author>
<abstract>
Ten dokument opisuje zasady postępowania z błędami zawartymi w pakietach
wchodzących w skład Gentoo Linux, które zostały udostępnione jego użytkownikom.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>1.2.7</version>
<date>2009-04-14</date>
<chapter>
<title>Zakres</title>
<section>
<title>Wspierane architektury</title>
<body>
<p>
Gentoo Linux oferowany jest dla wielu architektur. Cześć z tych architektur
posiada większą ilość deweloperów niż inne i z tego powodu zdolni są szybciej
odpowiadać na nowe błędy w zabezpieczeniach, podczas gdy podstawowym celem
projektu Gentoo Security jest zapewnienie poprawek bezpieczeństwa w tym samym
czasie dla każdej architektury. Warto przy tym uwzględnić także fakt, że
GLSA muszą być wypuszczane możliwie szybko, aby nasi użytkownicy zostali
poinformowani o błędzie i mogli zabezpieczyć swoje komputery.
</p>
<p>
Z tego powodu zespół bezpieczeństwa dzieli architektury Gentoo na dwie grupy:
<b>wspierane</b> i <b>niewspierane</b>.
</p>
<ul>
<li>
<b>Wspierane:</b> błędy rozpoznane w tych architekturach muszą posiadać
rozwiązanie zanim GLSA zostanie wydane
</li>
<li>
<b>Niewspierane:</b> użytkownicy tych architektur będą powiadamiani o nowych
błędach, jednak nie będziemy czekać na rozwiązanie błędów na tych
architekturach przed wypuszczeniem GLSA i zamknięciem błędu.
</li>
</ul>
<p>
Poniżej znajduje się lista aktualnie wspieranych architektur:
</p>
<table>
<tr>
<th>Wspierane architektury</th>
</tr>
<tr>
<ti>alpha</ti>
</tr>
<tr>
<ti>amd64</ti>
</tr>
<tr>
<ti>hppa</ti>
</tr>
<tr>
<ti>ppc</ti>
</tr>
<tr>
<ti>ppc64</ti>
</tr>
<tr>
<ti>sparc</ti>
</tr>
<tr>
<ti>x86</ti>
</tr>
</table>
<p>
Każda architektura może zostać włączona do wspieranych. Istnieją dwie proste
reguły, które muszą zostać spełnione, aby zostać oficjalnie wspieranym przez
projekt Gentoo Security:
</p>
<ul>
<li>
Mianować dewelopera, który jest pierwszą osobą kontaktującą się w sprawach
błędów bezpieczeństwa odnośnie danej architektury. Sprawdzimy czy dana osoba
jest odpowiedzialna za zagwarantowanie, że błędy bezpieczeństwa są
odpowiednio traktowane na określonej architekturze.
</li>
<li>
Zapoznać się opublikowanymi tutaj harmonogramami testowania i oznaczania
pakietów jako stabilne.
</li>
</ul>
</body>
</section>
<section>
<title>Release Engineering</title>
<body>
<p>
Zespół Release Engineering ("releng") zatrudnia dewelopera, który będzie
zajmował się koordynacją pomiędzy tym zespołem a zespołem Security.
</p>
<p>
Release Engineering informuje projekt Security kiedy będzie robiony pierwszy
snapshot drzewa na potrzeby mediów instalacyjnych. W czasie pomiędzy tą datą a
oficjalnym wydaniem Gentoo (okres przygotowań), osoba ta powinna być informowana
(poprzez CC) o wszystkich błędach, które mają związek z bezpieczeństwem systemu.
</p>
</body>
</section>
<section>
<title>Jądra</title>
<body>
<p>
Jądra nie są objęte przez system GLSA. Błędy oczywiście są zgłaszane i
naprawiane, ale <e>żaden raport GLSA</e> nie jest wydawany.
</p>
<note>
Ta zasada może się zmienić, gdy powstaną narzędzia do sprawdzania
bezpieczeństwa kolejnych wydań jądra.
</note>
</body>
</section>
<section>
<title>Niestabilne pakiety</title>
<body>
<p>
Zdarza się, że błąd zostanie znaleziony w pakiecie, który nie jest częścią
stabilnego drzewa. Jest to przypadek kiedy błąd jest regresją bezpieczeństwa w
nowszym (~ARCH) ebuildzie, ale starszy (stabilny) pakiet nie posiada tego błędu,
lub wtedy gdy w drzewie nigdy nie było stabilnego ebuilda danego pakietu. W
takim przypadku błąd cały czas musi być zgłoszony, po czym zostanie naprawiony,
ale <e>nie zostanie wydany GLSA</e> kiedy wszystko zostanie rozwiązane.
</p>
<note>
Polityka ta może zostać zmieniona w chwili kiedy nasze narzędzia zapewnią
bardziej kompleksową aktualizację ścieżek oraz gdy dołączy wystarczająca ilość
koordynatorów GLSA do zespołu bezpieczeństwa.
</note>
</body>
</section>
</chapter>
<chapter>
<title>Vulnerability feed</title>
<section>
<title>Opublikowane błędy</title>
<body>
<p>
Każdy błąd w bezpieczeństwie na powinien zostać poprzedzony wprowadzeniem
wpisu do <uri link="https://bugs.gentoo.org">Bugzilli</uri> jako produkt "Gentoo
Security" i komponent "Vulnerabilities" (przypisane do
<mail>security@gentoo.org</mail>). Główne listy bezpieczeństwa powinny posiadać
oficjalnie wybranych ludzi przydzielonych do nich, którzy powinni dbać o wpisy
do bugzilli dla wszystkich błędów w bezpieczeństwie umieszczonych na tych
listach.
</p>
</body>
</section>
<section>
<title>Poufne błędy</title>
<body>
<p>
Poufne błędy (czyli na przykład takie, które pochodzą z bezpośredniej wymiany
informacji między deweloperami lub zastrzeżonych list vendor-sec) powinno
traktować się w sposób specyficzny. Nie powinny one się pojawić jako publiczne
wpisy w bugzilli, ale jedynie w zastrzeżonych mediach takich jak prywatne sekcje
bugzilli lub narzędzie GLSAMaker. Powinny zostać one naprawione za pomocą
prywatnych kanałów komunikacyjnych pomiędzy koordynatorem GLSA, a osobą
zajmującą się pakietem.
</p>
<note>
Wymiana informacji dotycząca poufnych błędów powinna być odpowiednio kodowana.
Należy wysyłać je do określonych członków zespołu bezpieczeństwa oraz kodować
przy użyciu klucza GPG. Listę członków zespołu bezpieczeństwa znaleźć można na
stronie <uri link="http://security.gentoo.org">security.gentoo.org</uri>, ich
GPD ID można odnaleźć na <uri
link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">liście
deweloperów Gentoo Linux</uri>, a ich klucze na serwerze kluczy <uri
link="http://subkeys.pgp.net">subkeys.pgp.net</uri>.
</note>
</body>
</section>
</chapter>
<chapter>
<title>Dispatch</title>
<section>
<title>Poziom zagrożenia</title>
<body>
<p>
Aby zapewnić odpowiedni czas reakcji i procedury eskalacji, dla każdego błędu
należy przydzielić odpowiedni poziom zagrożenia. Poziom zagrożenia musi bazować
na tym jak powszechne jest narażone oprogramowanie wśród użytkowników Gentoo i
jak poważne są błędy.
</p>
<p>
Możemy użyć poniższych dwóch tabel do pomocy przy przydzielaniu poziomu
zagrożenia:
</p>
<table>
<tr>
<th>Jak powszechny jest dany pakiet</th>
<th>Zagrożona konfiguracja</th>
<th> </th>
</tr>
<tr>
<ti>Pakiet systemu</ti>
<ti>Domyślny lub określony</ti>
<ti>A</ti>
</tr>
<tr>
<ti>Powszechny pakiet (występuje prawdopodobnie na co najmniej 1/20
instalacji Gentoo)</ti>
<ti>Domyślny</ti>
<ti>A</ti>
</tr>
<tr>
<ti></ti>
<ti>Określony</ti>
<ti>B</ti>
</tr>
<tr>
<ti>Oprogramowanie marginalne (występuje przypuszczalnie na mniej niż 1/20
instalacji Gentoo)</ti>
<ti>Domyślny</ti>
<ti>B</ti>
</tr>
<tr>
<ti></ti>
<ti>Określony</ti>
<ti>C</ti>
</tr>
<tr>
<ti>Pakiet, który nigdy nie posiadał narażonej stabilnej wersji</ti>
<ti>Domyślny lub określony</ti>
<ti>~</ti>
</tr>
</table>
<table>
<tr>
<th>Przewidywany rodzaj błędu</th>
<th> </th>
<th>Odpowiednia ważność GLSA</th>
</tr>
<tr>
<ti>Całkowicie zdalny system: zdalne uruchamianie dowolnego kodu z
uprawnieniami superużytkownika</ti>
<ti>0</ti>
<ti>wysoki</ti>
</tr>
<tr>
<ti>Zdalne aktywne ujawnienie: bezpośrednie zdalne uruchomienie dowolnego kodu
z mniejszymi prawami lub prawami użytkownika na serwerze</ti>
<ti>1</ti>
<ti>wysoki</ti>
</tr>
<tr>
<ti>Eskalacja lokalnych zezwoleń: błąd w zabezpieczeniach pozwalający ujawnić
superużytkownika kiedy posiada się lokalny dostęp</ti>
<ti>1</ti>
<ti>wysoki</ti>
</tr>
<tr>
<ti>Zdalne bierne ujawnienie: zdalne uruchamianie dowolnego kodu poprzez
kuszenie użytkownika do odwiedzenia złośliwego serwera lub używanie złośliwych
danych</ti>
<ti>2</ti>
<ti>normalny</ti>
</tr>
<tr>
<ti>Globalne ujawnienie usług: ataki denial of service, hasła lub wycieki baz
danych, utrata danych (ataki symlink)</ti>
<ti>3</ti>
<ti>normalny</ti>
</tr>
<tr>
<ti>Pozostałe: Cross-Site Scripting, wyciek informacji...</ti>
<ti>4</ti>
<ti>niski</ti>
</tr>
</table>
<p>
Poniżej znajduje się tabela z listą poziomów zagrożenia. Podczas zgłaszania
błędu na bugzilli należy nadać jedną z tych wartości.
</p>
<table>
<tr>
<th>Poziom zagrożenia</th>
<th>Odpowiednia ocena</th>
<th>Opóźnienie</th>
<th>GLSA</th>
</tr>
<tr>
<ti>Blocker (Bloker)</ti>
<ti>A0, B0</ti>
<ti>1 dzień</ti>
<ti>tak</ti>
</tr>
<tr>
<ti>Critical (Krytyczny)</ti>
<ti>A1, C0</ti>
<ti>3 dni</ti>
<ti>tak</ti>
</tr>
<tr>
<ti>Major (Poważny)</ti>
<ti>A2, B1, C1</ti>
<ti>5 dni</ti>
<ti>tak</ti>
</tr>
<tr>
<ti>Normal (Normlany)</ti>
<ti>A3, B2, C2</ti>
<ti>10 dni</ti>
<ti>tak</ti>
</tr>
<tr>
<ti>Minor (Nieznaczny)</ti>
<ti>A4, B3, B4, C3</ti>
<ti>20 dni</ti>
<ti>?</ti>
</tr>
<tr>
<ti>Trivial (Trywialny)</ti>
<ti>C4, ~0, ~1, ~2, ~3, ~4</ti>
<ti>40 dni</ti>
<ti>nie</ti>
</tr>
</table>
<note>
Opóźnienie przedstawione w tej tabeli jest przedstawieniem maksymalnego czasu
pomiędzy wydaniem poprawki przez dewelopera pakietu, a wydaniem stabilnego
ebuildu i odpowiadającemu mu GLSA.
</note>
</body>
</section>
<section>
<title>Odbiór zgłoszeń błędów związanych z bezpieczeństwem</title>
<body>
<p>
Ktoś powinien odpowiednio zareagować na każde zgłoszenie jakie pojawia się na
<uri link="https://bugs.gentoo.org">Bugzilli</uri>, oto jak powinien postępować:
</p>
<ul>
<li>
Wyszukiwanie duplikatów: jeśli jakiś wpis opisuje błąd, który został już
zgłoszony powinien zostać on rozwiązany jako DUPLICATE (duplikat)
</li>
<li>
Sprawdzanie poprawności komponentu (component): jeżeli błąd nie jest słabym
punktem komponent powinien zostać odpowiednio zmieniony
</li>
<li>
Sprawdzanie czy błąd jest rzeczywiście słabym punktem i czy narażony jest
pakiet z dystrybucji Gentoo Linux, w przeciwnym wypadku należy rozwiązać
błąd jako INVALID.
</li>
</ul>
<p>
W czasie tego procesu może być konieczne zapytanie o szczegóły zgłaszającego
błąd. Błąd posiada status NEW (nowy) tak długo jak to będzie konieczne. Kiedy
błąd przejdzie testy poprawności (sanity tests) powinien zostać zaakceptowany, a
osoby zajmujące się utrzymaniem porządku na bugzilli (bug wranglers) powinno
postępować w sposób opisany poniżej:
</p>
<ul>
<li>
Zmiana nazwy błędu tak, aby zawierał wpis kategoria/nazwa-pakietu (na
przykład: "net-mail/clamav: DoS using RAR files")
</li>
<li>Ocena i przydzielenie poziomu ważności (patrz wyżej)</li>
<li>Ustawić status jako ASSIGNED</li>
<li>Zmienić pole statusu na poprawny kod ważności i statusu</li>
<li>Dodać cc do opiekunów pakietu zgodnie z plikiem metadata pakietu</li>
<li>Ustawić pole URL do raportu błędu upstream</li>
<li>
Wyszukać zarezerwowane lub przypisane identyfikatory CVE i dodanie ich do
tytułu raportu, a w przypadku braku prośba o przyznanie CVE
</li>
<li>
Opcjonalnie można przydzielić koordynatora GLSA dla danego błędu poprzez
dodanie nazwiska koordynatora do pola statusu.
</li>
</ul>
<warn>
Nie należy zmieniać poziomu ważności błędu jeśli został on już przyznany. Jeżeli
chcemy zwrócić uwagę deweloperów, należy użyć pola Priority.
</warn>
</body>
</section>
<section>
<title>Rama czasowa i procedury kopii zapasowej</title>
<body>
<p>
Poprawka (dispatch) powinna zostać wykonana w czasie jak najkrótszym od
zgłoszenia błędu, tak aby zagwarantować jak najkrótsze opóźnienia dla poważnych
błędów i równocześnie, aby okazać wdzięczność dla osoby zgłaszającej błąd.
Docelowym opóźnieniem jest 12 godzin. Security bug wrangler musi dostarczyć
listę możliwych koordynatorów GLSA z preferowanymi obszarami ekspertyz. Aby
zapewnić trwałą poprawkę, osoba zajmująca się sprzątaniem bugzilli z błędów
związanych z bezpieczeństw (security bug wrangler), powinna wykonywać
odpowiednie kopie zapasowe.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Korekcja błędów oraz szkic GLSA</title>
<section>
<title>Rola koordynatora GLSA</title>
<body>
<p>
Koordynator GLSA odpowiada za następujące zadania:
</p>
<ul>
<li>
Wyznaczyć co należy zrobić, aby zamknąć błąd (przykładowo zidentyfikować
poszukiwaną wersję zawierając poprawkę)
</li>
<li>
Jeżeli nie jest dostępna poprawka, należy upewnić się, że błąd jest
poprawnie zgłoszony do autora programu, pole statusu ustawić na
<c>upstream</c>
</li>
<li>
Jeśli poprawka jest już dostępna należy zaangażować opiekuna pakietu do
stworzenia i zaakceptowania ebuilda zawierającego daną łatkę oraz
ustawienia pola statusu na <c>ebuild</c>
</li>
<li>
Kiedy ebuild zostanie już zaakceptowany należy ocenić jakie słowa kluczowe
(keywords) potrzebne są dla załatanego ebuilda, zespoły poszczególnych
architektur powinny je przetestować i oznaczyć je jako stabilne na danej
architekturze (zespoły architektur [arch-teams] powinny znajdować się na
liście CC błędu), a na koniec należy oznaczyć pole statusu jako
<c>stable</c>
</li>
<li>
Opiekuni architektur (arch-maintainers) powinni oznaczyć ebuild jako
stabilny jeśli poprawiony ebuild nie posiada już błędów z poprzedniej wersji
</li>
<li>Równolegle, należy napisać szkic GLSA używając GLSAMaker tool</li>
<li>
Kiedy poprawny ebuild jest gotowy dla wszystkich wspieranych architektur
należy ustawić pole statusu na <c>glsa</c>.
</li>
</ul>
<note>
Jeżeli widoczny jest postęp w naprawie błędu, a przydzielony koordynator GLSA
nie reaguje, pozostali członkowie zespołu bezpieczeństwa mogą pomagać poprzez
uaktualnianie statusu.
</note>
</body>
</section>
<section>
<title>Rama czasowa i procesy eskalacji</title>
<body>
<p>
Jeżeli chcemy poznać docelowe opóźnienie w rozwiązaniu błędu, została
zdefiniowana liczba procedur eskalacji. Zawierają one:
</p>
<ul>
<li>
Kiedy błąd jest w fazie początkowej należy zwrócić na niego szczególną
uwagę oraz należy zmienić pole statusu na odpowiednik ze znakiem "+":
<c>upstream+</c>, <c>ebuild+</c>, <c>stable+</c> and <c>glsa+</c>
</li>
<li>
Jeżeli nie jest dostępna poprawka (status <c>upstream+</c>), musi zostać
podjęta decyzja o zamaskowaniu pakietu: zespół bezpieczeństwa może
zamaskować pakiet, który nie jest zależny sam od siebie, jednak należy
posiadać zezwolenie administratora TLP, aby zamaskować pakiet, który nie
jest samodzielny
</li>
<li>
Jeżeli opiekun nie stworzy ebuilda w 48 godzin po zgłoszeniu (status
<c>ebuild+</c>), zespół bezpieczeństwa sam powinien próbować stworzyć
odpowiedniego ebuilda
</li>
<li>
Jeżeli testowanie i przechodzenie pakietu do wersji stabilnej trwa zbyt
długo (status <c>stable+</c>) zespół bezpieczeństwa poprosi na kanałach IRC
oraz na liście gentoo-dev o większą ilość testerów. Ebuild zostanie
oznaczony jako stabilny przez nich samych jednak w przypadku gdy występują
problemy z stabilnością należy go zamaskować
</li>
<li>
Jeżeli koordynator nie zainteresuje się i nie naszkicuje GLSA (status
<c>glsa+</c>), wtedy inny członek zespołu bezpieczeństwa powinien
naszkicować GLSA i udostępnić go do recenzji dla innych.
</li>
</ul>
</body>
</section>
<section>
<title>Dobre zwyczaje dla błędów bezpieczeństwa</title>
<body>
<p>
Błędy bezpieczeństwa różnią się od innych błędów tym, że sposób aktualizacji
musi zostać przedstawiony użytkownikom poprzez GLSA jak najbardziej prosto.
Dlatego opiekunowie pakietów i koordynatorzy GLSA powinni zastosować się do
poniższych dobrych rad:
</p>
<ul>
<li>
Ebuild zawierający poprawkę bezpieczeństwa powinien posiadać swój własny
numer tak, aby uruchomił się w normalnym procesie aktualizacji systemu
</li>
<li>
Ebuild zawierający łatkę bezpieczeństwa powinien posiadać wyższy numer niż
poprzednio wydana wersja tak, aby prosty sposób aktualizacji mógł zostać
zaproponowany użytkownikowi
</li>
<li>
W przypadku poprawki, powinna ona zostać zaaplikowana jedynie do ostatniej
wersji. Nie ma potrzeby zmiany numeru wersji dla wszystkich ebuildów z
poprawką
</li>
<li>
Wersje posiadające błędy i słabe punkty powinny pozostać w drzewie dopóki
błąd nie otrzyma statusu <c>stable</c>, aby poprawnie ocenić jakie słowa
kluczowe są potrzebne dla poprawionej wersji.
</li>
</ul>
</body>
</section>
<section>
<title>Czasowe GLSA</title>
<body>
<p>
Jeśli błędy typu <e>blocker</e>, <e>critical</e> lub <e>major</e> nie mogą
zostać całkowicie naprawione z docelowym opóźnieniem, należy napisać
wcześniejsze ostrzeżenie GLSA z informacją. Ta wersja GLSA zostanie zastąpiona
finalną kiedy tylko ostateczna poprawka będzie dostępna.
</p>
<p>
Jeżeli powszechny pakiet (typ A lub B) zamaskowany jest z powodów
bezpieczeństwa, powinien zostać wydany czasowy GLSA dla wyjaśnienia przyczyn,
dlaczego w danej chwili pakiet jest niedostępny i/lub dlaczego użytkownicy
powinni odinstalować obecną wersję. Ta wersja GLSA zostanie zastąpiona wersją
finalną w chwili gdy poprawka będzie dostępna i pakiet zostanie odmaskowany.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Proces publikacji GLSA</title>
<section>
<title>Recenzowanie</title>
<body>
<p>
Kiedy GLSA jest już gotowe, powinno się wysłać je do recenzji. Przynajmniej
dwóch członków zespołu bezpieczeństwa musi zatwierdzić szkic GLSA. Kiedy już
szkic przejdzie ten proces powinien zostać mu przydzielony oficjalny numer
GLSA.
</p>
</body>
</section>
<section>
<title>Wydanie GLSA</title>
<body>
<p>
Kiedy GLSA przejdzie proces weryfikacji (po upewnieniu się, że ebuild znalazł
się już w stabilnej gałęzi drzewa) koordynator GLSA powinien zatwierdzić plik
XML GLSA w repozytorium CVS Gentoo. Kiedy tak zrobi GLSA automatycznie pojawi
się na <uri link="http://glsa.gentoo.org">oficjalnej stronie GLSA</uri> i w
<uri link="http://www.gentoo.org/rdf/en/glsa-index.rdf">RDF</uri>.
</p>
</body>
</section>
<section>
<title>Publikacja GLSA</title>
<body>
<p>
Wersja tekstowa GLSA musi zostać opublikowana w następujący sposób:
</p>
<table>
<tr>
<ti>Oficjalna lista mailingowa Gentoo Linux</ti>
<ti>
<mail link="gentoo-announce@lists.gentoo.org">gentoo-announce@lists.gentoo.org</mail>
</ti>
</tr>
<tr>
<ti>Bugtraq security mailing-list</ti>
<ti>
<mail link="bugtraq@securityfocus.com">bugtraq@securityfocus.com</mail>
</ti>
</tr>
<tr>
<ti>Full-disclosure security mailing-list</ti>
<ti>
<mail link="full-disclosure@lists.grok.org.uk">
full-disclosure@lists.grok.org.uk
</mail>
</ti>
</tr>
<tr>
<ti>Linuxsecurity.com advisories service</ti>
<ti>
<mail link="security-alerts@linuxsecurity.com">
security-alerts@linuxsecurity.com
</mail>
</ti>
</tr>
<tr>
<ti>Gentoo Linux announcement forum</ti>
<ti><uri>http://forums.gentoo.org/viewforum.php?f=16</uri></ti>
</tr>
</table>
<p>
Powinna zostać wysłana jedna wiadomość elektroniczna, z poniższymi danymi:
</p>
<ul>
<li>Pole <c>To:</c> musi zostać ustawione na gentoo-anounce</li>
<li>Pole <c>Cc:</c> musi zawierać pozostałe adresy poczty elektronicznej</li>
<li>
Pole <c>From:</c> i <c>Return-Path:</c> musi zostać ustawiony adres
koordynatora GLSA w domenie @gentoo.org
</li>
<li>
Pole <c>Subject:</c> musi wyglądać następująco "[ GLSA XXXXYY-ZZ ] Twój
błąd"
</li>
<li>Treść powinna zawierać jedynie wersję tekstową GLSA</li>
<li>
Wiadomość musi zostać podpisana przy użyciu klucza GPG koordynatora GLSA.
</li>
</ul>
<note>
Klucze identyfikacyjne deweloperów można znaleźć na
<uri link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">
liście deweloperów</uri> Gentoo Linux. Wszystkie klucze GPG zespołu
bezpieczeństwa opublikowane są na publicznych serwerach kluczy, włączając w to
<uri link="http://subkeys.pgp.net/">subkeys.pgp.net</uri>.
</note>
<note>
Aby zminimalizować ryzyko błędów w procesie publikacji, publikacja na forum jest
wykonywana automatycznie kiedy tylko automat dostanie zawiadomienie.
</note>
<p>
Kiedy GLSA zostanie opublikowane odpowiadający mu błąd powinien zostać
rozwiązany jako FIXED z numerem GLSA w sekcji komentarzy danego błędu.
</p>
</body>
</section>
<section>
<title>Errata GLSA</title>
<body>
<p>
Zdarzają się sytuacje kiedy podczas procesu recenzji przez innych koordynatorów
prześliźnie się błąd i zostanie opublikowane błędne wydanie GLSA. W zależności
od ważności błędu, należy stosować następującą politykę erraty:
</p>
<table>
<tr>
<th>Typ erraty GLSA</th>
<th>Zalecane działania</th>
</tr>
<tr>
<ti>Typ: prezentacja, gramatyka lub literówka.</ti>
<ti>Nie robimy nic.</ti>
</tr>
<tr>
<ti>Błąd w tytule: tytuł odnosi się do innego pakietu lub nie opisuje błędu w
poprawny sposób.</ti>
<ti>Powinna zostać opublikowana errata GLSA, zastępując błędną.</ti>
</tr>
<tr>
<ti>Błąd w opisie: problem nie jest opisany odpowiednio.</ti>
<ti>Kod XML w GLSA powinien być jedynie poprawiony bez wydawania nowego
GLSA.</ti>
</tr>
<tr>
<ti>Pominięcie: GLSA jest poprawne, ale niekompletne. Trzeba zaktualizować
inny pakiet, aby zabezpieczyć się przed danym błędem.</ti>
<ti>Oddzielne wydanie GLSA powinno zostać opublikowane dla innego pakietu
zawierającego błąd.</ti>
</tr>
<tr>
<ti>Błąd w dotkniętym/niedotkniętym numerze wersji, jednak ludzie używający
stabilnych pakietów i ci, którzy zastosowali się do instrukcji z GLSA są
chronieni.</ti>
<ti>Kod XML w GLSA powinien zostać jedynie poprawiony bez wydawania nowego
GLSA.</ti>
</tr>
<tr>
<ti>Błąd w dotkniętym/niedotkniętym numerze wersji, użytkownicy stosujący
instrukcje zawarte w GLSA nie są chronieni</ti>
<ti>Powinna zostać opublikowana errata GLSA, zastępująca błędną</ti>
</tr>
</table>
</body>
</section>
</chapter>
</guide>
|
GitWeb