[gentoo-commits] gentoo commit in xml/htdocs/security/it: coordinator_guide.xml

["Agostino Sarubbo (ago)" <ago@gentoo.org>]

ago         12/11/07 12:12:56

  Modified:             coordinator_guide.xml
  Log:
  Version 0.9, revision 1.26 of EN CVS

Revision  Changes    Path
1.11                 xml/htdocs/security/it/coordinator_guide.xml

file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.11&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.11&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/security/it/coordinator_guide.xml?r1=1.10&r2=1.11

Index: coordinator_guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- coordinator_guide.xml	6 Nov 2012 14:18:08 -0000	1.10
+++ coordinator_guide.xml	7 Nov 2012 12:12:56 -0000	1.11
@@ -1,6 +1,6 @@
 <?xml version='1.0' encoding="UTF-8"?>
 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v 1.10 2012/11/06 14:18:08 ago Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v 1.11 2012/11/07 12:12:56 ago Exp $ -->
 
 <guide lang="it">
 <title>Guida per il Coordinatore dei GLSA</title>
@@ -17,6 +17,9 @@
 <author title="Autore">
   <mail link="rbu@gentoo.org">Robert Buchholz</mail>
 </author>
+<author title="Author">
+  <mail link="a3li@gentoo.org">Alex Legler</mail>
+</author>
 <author title="Traduzione">
   <mail link="dungeon01@gmail.com">Dungeon01</mail>
 </author>
@@ -33,8 +36,8 @@
 <!--Consultare  http://creativecommons.org/licenses/by-sa/1.0 -->
 <license/>
 
-<version>0.8.8</version>
-<date>2009-05-09</date>
+<version>0.9</version>
+<date>2011-05-15</date>
 
 <chapter>
 <title>Prerequisiti</title>
@@ -181,8 +184,7 @@
 <p>
 Le vulnerabilità sono trattate utilizzando una procedura a parte. Per
 distinguerle facilmente dagli altri bug, esse vengono archiviate sotto la
-categoria <c>Kernel</c>. I bug relativi al Kernel non risultano nei GLSA ma
-hanno il proprio meccanismo di pubblicazione (Gentoo KISS).
+categoria <c>Kernel</c>. I bug relativi al Kernel non risultano nei GLSA.
 </p>
 
 </body>
@@ -226,7 +228,7 @@
 conosciuta come data d'embargo odata di rilascio coordinato. I bug limitati
 hanno la checkbox "Gentoo Security" selezionata, e quindi possono essere
 raggiunti solo da membri del Team di Sicurezza di Gentoo. Gli attori esterni (il
-manutentore del pacchetto, il tester dell'architettura, Release Engineering)
+manutentore del pacchetto, il tester dell'architettura)
 possono essere aggiunti in base nominale, gli alias non dovrebbero mai essere
 utilizzati (questo perché gli alias sono troppo larghi e non permettono commenti
 ai bug).
@@ -297,13 +299,6 @@
   <ti>Lo stato effettivo del bug, con informazioni aggiuntive(opzionali)</ti>
   <ti>[ebuild+]</ti>
 </tr>
-<tr>
-  <ti>coordinatore</ti>
-  <ti>
-    Il nickname del coordinatore assegnato al bug in questione, opzionalmente
-  </ti>
-  <ti>koon</ti>
-</tr>
 </table>
 
 <p>
@@ -370,6 +365,16 @@
     Il GLSA è in ritardo, ogni coordinatore di GLSA può correggerlo ed inviarlo
   </ti>
 </tr>
+<tr>
+<ti>cleanup</ti>
+<ti>Si aspetta che il manutentore del pacchetto rimuova le versioni vulnerabili 
+dall'albero di portage</ti>
+</tr>
+<tr> 
+<ti>cleanup+</ti>
+<ti>Nessuna risposta dal manutentore del pacchetto. Il team di sicurezza 
+potrebbe rimuovere le versioni vulnerabili dall'albero di portage se necessario</ti>
+</tr>
 </table>
 
 <p>
@@ -393,11 +398,6 @@
   <ti>upstream+, ebuild+</ti>
 </tr>
 <tr>
-  <ti>Arch names</ti>
-  <ti>Quando solo una o due architetture supportate stanno bloccando il bug</ti>
-  <ti>stable+</ti>
-</tr>
-<tr>
   <ti>tempglsa</ti>
   <ti>
     Quando un GLSA temporaneo è stato pubblicato come soluzione temporanea
@@ -420,10 +420,7 @@
   <ti>C0 [stable]</ti>
 </tr>
 <tr>
-  <ti>A3 [ebuild] jaervosz</ti>
-</tr>
-<tr>
-  <ti>B1 [stable+ amd64] koon</ti>
+<ti>B1 [stable blocked]</ti>
 </tr>
 </table>
 
@@ -436,12 +433,13 @@
 <p>
 Quando la correzione non è disponibile dallo sviluppatore originale e/o non è
 stata rilasciata una patch ufficiale per risolvere il problema, il bug si trova
-in stato [upstream]. Se la soluzione deve essere trovata dagli sviluppatori
-Gentoo, il bug è in stato [inhouse]. Se è disponibile una correzione, il bug si
-trova nello stato [ebuild]. Se la correzione è stata inserita in portage, il
-bug assume lo stato [stable]. Quando una correzione è presente in portage con
-tutte le chiavi richieste correttamente configurate, il bug entra in stato
-[glsa].
+in stato <c>[upstream]</c>. Se è disponibile una correzione, il bug si
+trova nello stato <c>[ebuild]</c>. Se la correzione è stata inserita in portage, il prossimo
+passo è quello di stabilizzare, quindi il bug assume lo stato <c>[stable]</c>. 
+Quando una correzione è presente in portage con tutte le parole chiave correttamente
+configurate e se il problema è abbastanza severo da garantire un GLSA, il bug è nello stato
+<c>[glsa]</c>. Se il problema non è abbastanza severo, il voto per il GLSA è il prossimo passo, 
+quindi lo stato sarà <c>[glsa?]</c>.
 </p>
 
 </body>
@@ -451,20 +449,20 @@
 <body>
 
 <p>
-Nello stato [upstream], si è in attesa della pubblicazione di una versione della
-correzione o di una patch decente. Questo stato richiede controlli regolari
+Nello stato <c>[upstream],</c> si è in attesa della pubblicazione di una versione corretta 
+o di una patch decente. Questo stato richiede controlli regolari
 degli sviluppatori originali per informazioni: mailing list di sviluppo e
-annunci, siti internet, database di bug database, CVS ove possibile, sono tutte
+annunci, siti internet, database di bug database, VCS ove possibile, sono tutte
 fonti importanti d'informazioni. Patch non ufficiali devono essere considerate
 soltanto se lo sviluppatore originale non reagisce alla vulnerabilità, e devono
 essere controllate più volte per assicurarsi che non siano maligne. Quando viene
 annunciata una nuova versione di una correzione, o viene rilasciata una nuova
-patch, il bug entra nello stato [ebuild].
+patch, il bug entra nello stato <c>[ebuild]</c>.
 </p>
 
 <p>
 Se dal ramo di sviluppo originale non v'è reazione né patch alcuna, si entra
-nello stato [upstream+]. L'unica opzione consiste nell'applicare una
+nello stato <c>[upstream+]</c>. L'unica opzione consiste nell'applicare una
 security-mask al pacchetto vulnerabile e pubblicare un glsa temporaneo se
 necessario. Si veda la politica corrente per ulteriori dettagli inerenti alla
 procedura d'approvazione del security-masking. Il pannello di stato dovrebbe
@@ -479,25 +477,25 @@
 <body>
 
 <p>
-In stato [ebuild], bisogna identificare il manutentore del pacchetto, ed
+In stato <c>[ebuild]</c>, bisogna identificare il manutentore del pacchetto, ed
 imporgli di generare una correzione. Le fonti per identificare il gruppo o lo
 sviluppatore responsabile della manutenzione del pacchetto sono il file
 metadata.xml, presente in portage nella directory relativa del pacchetto, ed il
 file Changelog che mostra chi ha effettuato gli ultimi aggiornamenti di
-versione. Mettere in cc: il gruppo e/o il mantenitore responsabile del pacchetto
+versione. Mettere in cc: il gruppo e il mantenitore responsabile del pacchetto
 inerente al bug e chiedere che venga fornita un ebuild per la versione della
 correzione corrente. Controllare periodicamente che un ebuild non sia stato
 inserito in portage senza alcun commento riguardo il bug (a volte accade).
-Quando l'ebuild appare, il bug entra in stato [stable]
+Quando l'ebuild appare, il bug entra in stato <c>[stable]</c>.
 </p>
 
 <p>
-Se il manutentore non lo rivela, si arriva allo stato [ebuild+]. In casi di
+Se il manutentore non lo rivela, si arriva allo stato <c>[ebuild+]</c>. In casi di
 una versione correttiva disponibile, testare se un semplice incremento di
-versione funziona (basta rinominare l'ebuild all'ultima versione e farne
+versione funziona (basta rinominare l'ebuild alla versione necessaria e farne
 l'emerge). Se è disponibile solamente una patch, testare se quest'ultima viene
-applicata correttamente. A questo punto trovare un wrangler di bug di sicurezza
-con diritti x86 per eseguire l'incremento di versione e segnare l'ebuild ~ per
+applicata correttamente. A questo punto trovare uno sviluppatore con accesso al
+repository gentoo-x86 per eseguire l'incremento di versione e segnare l'ebuild ~ per
 testarlo.
 </p>
 
@@ -507,7 +505,7 @@
 pacchetto non mantenuto e pubblicare un GLSA temporaneo, se necessario. Si veda
 la politica corrente per ulteriori dettagli inerenti la procedura
 d'approvazione del security-masking. Il pannello di stato dovrebbe quindi essere
-flaggato con le keyword "masked" e/o "tempglsa" e la bug severity impostata a
+flaggato con le keyword <c>masked</c> e/o <c>tempglsa</c> e la bug severity impostata a
 <c>enhancement</c>.
 </p>
 
@@ -518,7 +516,7 @@
 <body>
 
 <p>
-Nello stato [stable], bisogna determinare di quali chiavi l'ebuild fornito
+Nello stato <c>[stable]</c>, bisogna determinare di quali chiavi l'ebuild fornito
 necessita prima che il GLSA venga pubblicato. Ciò può essere ingannevole.
 Bisogna considerare ogni versione attualmente presente in portage in modo
 che l'ebuild abbia <e>le stesse o più keyword "stable"</e> di qualsiasi altro
@@ -552,21 +550,21 @@
 È possibile usare <uri>http://packages.gentoo.org</uri> per aiutarsi nel
 determinare le keyword necessarie. Qualora i pacchetti interessati fossero stati
 rimossi troppo presto dal manutentore del pacchetto stesso, usare l'accesso
-<uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/">CVS</uri> per cercare
+<uri link="http://sources.gentoo.org/cgi-bin/viewvc.cgi">ViewVC</uri> per cercare
 nell'archivio delle vecchie keyword.
 </note>
 
 <p>
 Una volta determinate (ed inserite come riferimento nel bug) le keyword
 necessarie, mettere in CC i team di sviluppo delle varie architetture, chiedendo
-loro di contrassegnare l'ebuild come "stable" o ~ di conseguenza. Per
+loro di contrassegnare l'ebuild come "stable" o "testing" di conseguenza. Per
 assicurarsi che i team delle architetture prendano in carico il bug, non
 dimenticarsi di aggiungere "STABLEREQ" al campo "Keywords" del bug. Gli alias
 per le varie architetture sono del tipo architettura@gentoo.org (x86@gentoo.org,
 ppc@gentoo.org...). Tutte le architetture (incluse quelle "non supportate")
 devono essere contattate. Ma si tenga conto che solo le architetture
 "supportate" (come definite da regolamento) sono necessarie prima che il bug
-possa avanzare allo stato [glsa]. Controllare periodicamente per verificare se
+possa avanzare allo stato <c>[glsa]</c>. Controllare periodicamente per verificare se
 vi sono nuove keyword nell'ebuild, dato che talvolta queste vengono modificate
 senza lasciare nessun commento nel bug. Non appena le keyword richieste sono
 state inserite nel bug per tutte le architetture supportate, il bug entra nello
@@ -574,17 +572,11 @@
 </p>
 
 <p>
-Durante il periodo di preparazione al rilascio si dovrebbe inoltre inserire in
-CC Release Engineering (release@gentoo.org) su tutti i bug aventi stato
-[stable],
-</p>
-
-<p>
 Se i team di sviluppo per le relative architetture impiegano troppo tempo nel
 testare o cambiare le proprie keyword, o rifiutano di contrassegnare come
 stabile un pacchetto per problemi non ancora risolti, il bug assume lo stato di
-[stable+]. Bisogna rintracciare i mantenitori delle varie architetture affinché
-contrassegnino come stabile il pacchetto, e diano supporto nel testing dello
+<c>[stable+]</c>. Bisogna rintracciare i mantenitori delle varie architetture affinché
+contrassegnino come stabile il pacchetto o diano supporto nel testing dello
 stesso. Bisognerebbe inoltre convincere gli sviluppatori per le varie
 architetture che se scoprono un bug in un'ebuild che era già presente nelle
 precedenti versioni "stable", l'ebuild dovrebbe essere contrassegnata come
@@ -602,21 +594,48 @@
 <body>
 
 <p>
-Nello stato [glsa], il bug di sicurezza è stato corretto. Bisogna pubblicare il
+Nello stato <c>[glsa]</c>, il bug di sicurezza è stato corretto. Bisogna pubblicare il
 GLSA o semplicemente chiudere il bug senza GLSA. Il regolamento determina in
 quali casi un GLSA sia necessario e in quali casi non lo è. Vi sono anche
 situazioni nelle quali è necessario un voto per definire se un GLSA è necessario
-o meno. Se almeno due membri del Team di sicurezza votano per "no GLSA", allora
-nessun GLSA dovrebbe essere pubblicato. Il bug rimane in stato [glsa] finché non
+o meno(<c>[glsa?]</c>). Se almeno due membri del Team di sicurezza votano per "no GLSA", allora
+nessun GLSA dovrebbe essere pubblicato. Il bug rimane in stato <c>[glsa]</c> finché non
 viene pubblicato il GLSA.
 </p>
 
 <p>
 Quando è necessario un GLSA, ma non è stato pubblicato nulla, il bug entra nello
-stato [glsa+]. Questo è il caso in cui il coordinatore GLSA assegnato non ha
-steso e/o rivisto e/o inviato il proprio GLSA. Gli altri membri del team di
-sicurezza dovrebbero prendere il controllo della situazione a questo punto e
-finalizzare il GLSA.
+stato <c>[glsa+]</c>. Questo è il caso quando ci sono ritardi durante la scrittura della 
+bozza, revisione, o invio dell' advisory. Qualsiasi membro del team di sicurezza potrebbe
+prendere il comando e concludere il GLSA.
+</p>
+
+</body>
+</section>
+<section>
+<title> Bug nello stato [cleanup]</title>
+<body>
+
+<p>
+Questo stato non è in ordine come gli altri. Esso viene usato per
+denotare che il manutentore deve rimuovere gli ebuild vulnerabili dall'albero di portage.
+</p>
+
+<p>
+Ad esempio il pacchetto <c>foo</c> è vulnerabile in versioni precedenti a 1.23.
+La versione 1.24 viene aggiunta all'albero di portage ed è già stabile (ad esempio la 
+stabilizzazione è stata fatta prima che si conoscesse la vulnerabilità), solo i vecchi ebuild 
+devono essere rimossi. Il prossimo stato in questo caso sarà <c>[glsa]</c> o <c>[glsa?]</c> in 
+base alla severità.
+</p>
+
+<p>
+Un altro caso potrebbe essere quando un pacchetto è stato aggiornato e tutti gli steps sono stati
+eseguiti (ad esempio il GLSA è stato inviato o il team ha deciso di non inviarne), ma gli ebuild 
+vulnerabili dovrebbero essere rimossi per evitare che gli utenti, accidentalmente, possano 
+installarli; il bug dovrebbe rimanere aperto e avere uno stato di <c>[cleanup]</c>.
+Questo non è solitamente necessario ma può essere utilizzato in base al caso quando il 
+team di sicurezza ha un elevato interesse a rimuovere gli ebuild velnerabili per qualsiasi ragione.
 </p>
 
 </body>
@@ -630,8 +649,8 @@
 <body>
 
 <p>
-I bug confidenziali dovrebbero seguire questo modello: "RATING [status]
-coordinatore / KEYWORD CRD", dove:
+I bug confidenziali dovrebbero seguire questo modello: <c>RATING [status]
+coordinatore / KEYWORD CRD</c>, dove:
 </p>
 
 <table>
@@ -653,11 +672,6 @@
   <ti>[ebuild+]</ti>
 </tr>
 <tr>
-  <ti>coordinator</ti>
-  <ti>Il nickname del coordinatore assegnato al bug in questione, opzionale</ti>
-  <ti>koon</ti>
-</tr>
-<tr>
   <ti>KEYWORD</ti>
   <ti>
     Il livello confidenziale del bug, può essere CLASSIFIED, CONFIDENTIAL,
@@ -715,8 +729,8 @@
 
 <p>
 I bug confidenziali e classificati richiedono maggiore attenzione. L'ebuild e i
-file per correggere la vulnerabilità NON dovrebbero essere aggiunti al CVS del
-portage, e nessun aspetto di quei bug dovrebbe essere discusso in pubblico.
+file per correggere la vulnerabilità NON dovrebbero essere aggiunti all'albero di portage, 
+e nessun aspetto di qusti bug dovrebbe essere discusso in pubblico.
 Patch o archivi tarball provenienti da overlay di portage possono comunque
 essere allegati al bug. I collaudatori dovranno installare il proprio overlay
 per testarlo. L'idea con questi bug è di preparare l'ebuild e farlo testare