| 1 |
rane 08/02/23 12:43:34 |
| 2 |
|
| 3 |
Modified: vulnerability-policy.xml |
| 4 |
Log: |
| 5 |
-> 1.19 |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.7 xml/htdocs/security/pl/vulnerability-policy.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/pl/vulnerability-policy.xml?rev=1.7&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/pl/vulnerability-policy.xml?rev=1.7&content-type=text/plain |
| 12 |
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/pl/vulnerability-policy.xml?r1=1.6&r2=1.7 |
| 13 |
|
| 14 |
Index: vulnerability-policy.xml |
| 15 |
=================================================================== |
| 16 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/security/pl/vulnerability-policy.xml,v |
| 17 |
retrieving revision 1.6 |
| 18 |
retrieving revision 1.7 |
| 19 |
diff -u -r1.6 -r1.7 |
| 20 |
--- vulnerability-policy.xml 12 Mar 2007 00:03:45 -0000 1.6 |
| 21 |
+++ vulnerability-policy.xml 23 Feb 2008 12:43:34 -0000 1.7 |
| 22 |
@@ -1,15 +1,21 @@ |
| 23 |
<?xml version='1.0' encoding="UTF-8"?> |
| 24 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 25 |
|
| 26 |
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/pl/vulnerability-policy.xml,v 1.6 2007/03/12 00:03:45 shadoww Exp $ --> |
| 27 |
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/pl/vulnerability-policy.xml,v 1.7 2008/02/23 12:43:34 rane Exp $ --> |
| 28 |
|
| 29 |
<guide link="/security/pl/vulnerability-policy.xml" lang="pl"> |
| 30 |
<title>Zasady postępowania z błędami bezpieczeństwa w Gentoo</title> |
| 31 |
<author title="Autor"> |
| 32 |
<mail link="koon@g.o">Thierry Carrez</mail> |
| 33 |
</author> |
| 34 |
+<author title="Autor"> |
| 35 |
+ <mail link="jaervosz@g.o">Sune Kloppenborg Jeppesen</mail> |
| 36 |
+</author> |
| 37 |
+<author title="Autor"> |
| 38 |
+ <mail link="vorlon@g.o">Matthias Geerdsen</mail> |
| 39 |
+</author> |
| 40 |
<author title="Tłumacz"> |
| 41 |
- <mail link="shadoww@g.o">Damian Kuras</mail> |
| 42 |
+ <mail link="shadow"/> |
| 43 |
</author> |
| 44 |
|
| 45 |
<abstract> |
| 46 |
@@ -21,8 +27,8 @@ |
| 47 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 48 |
<license/> |
| 49 |
|
| 50 |
-<version>1.2.5</version> |
| 51 |
-<date>March 4, 2007</date> |
| 52 |
+<version>1.2.6</version> |
| 53 |
+<date>2008-02-13</date> |
| 54 |
|
| 55 |
<chapter> |
| 56 |
<title>Zakres</title> |
| 57 |
@@ -110,6 +116,24 @@ |
| 58 |
</body> |
| 59 |
</section> |
| 60 |
<section> |
| 61 |
+<title>Release Engineering</title> |
| 62 |
+<body> |
| 63 |
+ |
| 64 |
+<p> |
| 65 |
+Zespół Release Engineering ("releng") zatrudnia dewelopera, który będzie |
| 66 |
+zajmował się koordynacją pomiędzy tym zespołem a zespołem Security. |
| 67 |
+</p> |
| 68 |
+ |
| 69 |
+<p> |
| 70 |
+Release Engineering informuje projekt Security kiedy będzie robiony pierwszy |
| 71 |
+snapshot drzewa na potrzeby mediów instalacyjnych. W czasie pomiędzy tą datą a |
| 72 |
+oficjalnym wydaniem Gentoo (okres przygotowań), osoba ta powinna być informowana |
| 73 |
+(poprzez CC) o wszystkich błędach, które mają związek z bezpieczeństwem systemu. |
| 74 |
+</p> |
| 75 |
+ |
| 76 |
+</body> |
| 77 |
+</section> |
| 78 |
+<section> |
| 79 |
<title>Jądra</title> |
| 80 |
<body> |
| 81 |
|
| 82 |
@@ -450,21 +474,22 @@ |
| 83 |
</li> |
| 84 |
<li> |
| 85 |
Jeśli poprawka jest już dostępna należy zaangażować opiekuna pakietu do |
| 86 |
- stworzenia i zaakceptowania ebuilda zawierającego daną łatkę (opiekun pakietu |
| 87 |
- powinien zostać dodany do list CC błędu) oraz ustawienia pola statusu na |
| 88 |
+ stworzenia i zaakceptowania ebuilda zawierającego daną łatkę (opiekun |
| 89 |
+ pakietu oraz kontakt z releng (w czasie przygotowań do wydania) powinni |
| 90 |
+ zostać dodani do list CC błędu) oraz ustawienia pola statusu na |
| 91 |
<c>ebuild</c> |
| 92 |
</li> |
| 93 |
<li> |
| 94 |
Kiedy ebuild zostanie już zaakceptowany należy ocenić jakie słowa kluczowe |
| 95 |
(keywords) potrzebne są dla załatanego ebuilda, zespoły poszczególnych |
| 96 |
architektur powinny je przetestować i oznaczyć je jako stabilne na danej |
| 97 |
- architekturze (zespoły architektur [arch-teams] powinny znajdować się na liście |
| 98 |
- CC błędu), a na koniec należy oznaczyć pole statusu jako <c>stable</c> |
| 99 |
+ architekturze (zespoły architektur [arch-teams] powinny znajdować się na |
| 100 |
+ liście CC błędu), a na koniec należy oznaczyć pole statusu jako |
| 101 |
+ <c>stable</c> |
| 102 |
</li> |
| 103 |
<li> |
| 104 |
Opiekuni architektur (arch-maintainers) powinni oznaczyć ebuild jako |
| 105 |
- stabilny jeśli poprawiony ebuild nie posiada już błędów z poprzedniej |
| 106 |
- wersji |
| 107 |
+ stabilny jeśli poprawiony ebuild nie posiada już błędów z poprzedniej wersji |
| 108 |
</li> |
| 109 |
<li>Równolegle, należy napisać szkic GLSA używając GLSAMaker tool</li> |
| 110 |
<li> |
| 111 |
@@ -498,9 +523,10 @@ |
| 112 |
</li> |
| 113 |
<li> |
| 114 |
Jeżeli nie jest dostępna poprawka (status <c>upstream+</c>), musi zostać |
| 115 |
- podjęta decyzja o zamaskowaniu pakietu: zespół bezpieczeństwa może zamaskować |
| 116 |
- pakiet, który nie jest zależny sam od siebie, jednak należy posiadać zezwolenie |
| 117 |
- administratora TLP, aby zamaskować pakiet, który nie jest samodzielny |
| 118 |
+ podjęta decyzja o zamaskowaniu pakietu: zespół bezpieczeństwa może |
| 119 |
+ zamaskować pakiet, który nie jest zależny sam od siebie, jednak należy |
| 120 |
+ posiadać zezwolenie administratora TLP, aby zamaskować pakiet, który nie |
| 121 |
+ jest samodzielny |
| 122 |
</li> |
| 123 |
<li> |
| 124 |
Jeżeli opiekun nie stworzy ebuilda w 48 godzin po zgłoszeniu (status |
| 125 |
@@ -516,8 +542,8 @@ |
| 126 |
</li> |
| 127 |
<li> |
| 128 |
Jeżeli koordynator nie zainteresuje się i nie naszkicuje GLSA (status |
| 129 |
- <c>glsa+</c>), wtedy inny członek zespołu bezpieczeństwa powinien naszkicować |
| 130 |
- GLSA i udostępnić go do recenzji dla innych. |
| 131 |
+ <c>glsa+</c>), wtedy inny członek zespołu bezpieczeństwa powinien |
| 132 |
+ naszkicować GLSA i udostępnić go do recenzji dla innych. |
| 133 |
</li> |
| 134 |
</ul> |
| 135 |
|
| 136 |
@@ -573,7 +599,7 @@ |
| 137 |
|
| 138 |
<p> |
| 139 |
Jeżeli powszechny pakiet (typ A lub B) zamaskowany jest z powodów |
| 140 |
-bezpieczeństwa, powinien zostać wydany czasowy GLSA dla wyjaśnienia przyczy, |
| 141 |
+bezpieczeństwa, powinien zostać wydany czasowy GLSA dla wyjaśnienia przyczyn, |
| 142 |
dlaczego w danej chwili pakiet jest niedostępny i/lub dlaczego użytkownicy |
| 143 |
powinni odinstalować obecną wersję. Ta wersja GLSA zostanie zastąpiona wersją |
| 144 |
finalną w chwili gdy poprawka będzie dostępna i pakiet zostanie odmaskowany. |
| 145 |
@@ -663,7 +689,7 @@ |
| 146 |
<li>Pole <c>To:</c> musi zostać ustawione na gentoo-anounce</li> |
| 147 |
<li>Pole <c>Cc:</c> musi zawierać pozostałe adresy poczty elektronicznej</li> |
| 148 |
<li> |
| 149 |
- Pole <c>From:</c> i <c>Return-Path:</c> musi zostać ustustawione adres |
| 150 |
+ Pole <c>From:</c> i <c>Return-Path:</c> musi zostać ustawiony adres |
| 151 |
koordynatora GLSA w domenie @gentoo.org |
| 152 |
</li> |
| 153 |
<li> |
| 154 |
@@ -722,11 +748,11 @@ |
| 155 |
</tr> |
| 156 |
<tr> |
| 157 |
<ti>Błąd w opisie: problem nie jest opisany odpowiednio.</ti> |
| 158 |
- <ti>Kod XML w GLSA powpowinienstać jedynie poprawiony bez wydawania nowego |
| 159 |
-GLSA.</ti> |
| 160 |
+ <ti>Kod XML w GLSA powinien być jedynie poprawiony bez wydawania nowego |
| 161 |
+ GLSA.</ti> |
| 162 |
</tr> |
| 163 |
<tr> |
| 164 |
- <ti>Pominięcie: GLSA jest poprawne, ale niekompletne. Trzeba zaazaktualizować |
| 165 |
+ <ti>Pominięcie: GLSA jest poprawne, ale niekompletne. Trzeba zaktualizować |
| 166 |
inny pakiet, aby zabezpieczyć się przed danym błędem.</ti> |
| 167 |
<ti>Oddzielne wydanie GLSA powinno zostać opublikowane dla innego pakietu |
| 168 |
zawierającego błąd.</ti> |
| 169 |
|
| 170 |
|
| 171 |
|
| 172 |
-- |
| 173 |
gentoo-commits@l.g.o mailing list |
Archives