diff options
Diffstat (limited to 'xml/htdocs/security/pl/vulnerability-policy.xml')
| -rw-r--r-- | xml/htdocs/security/pl/vulnerability-policy.xml | 782 |
1 files changed, 782 insertions, 0 deletions
diff --git a/xml/htdocs/security/pl/vulnerability-policy.xml b/xml/htdocs/security/pl/vulnerability-policy.xml new file mode 100644 index 00000000..b8e9ae69 --- /dev/null +++ b/xml/htdocs/security/pl/vulnerability-policy.xml @@ -0,0 +1,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> |