* [gentoo-commits] gentoo commit in xml/htdocs/security/it: coordinator_guide.xml
@ 2007-11-11 22:02 Davide Cendron (scen)
0 siblings, 0 replies; 7+ messages in thread
From: Davide Cendron (scen) @ 2007-11-11 22:02 UTC (permalink / raw
To: gentoo-commits
scen 07/11/11 22:02:22
Modified: coordinator_guide.xml
Log:
Version 0.8.4, revision 1.18 of EN CVS
Revision Changes Path
1.4 xml/htdocs/security/it/coordinator_guide.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.4&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.4&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?r1=1.3&r2=1.4
Index: coordinator_guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- coordinator_guide.xml 4 May 2005 20:43:35 -0000 1.3
+++ coordinator_guide.xml 11 Nov 2007 22:02:22 -0000 1.4
@@ -1,964 +1,1337 @@
-<?xml version='1.0' encoding="UTF-8"?>
-<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<guide link="/security/it/coordinator_guide.xml" lang="it">
-<title>Guida per il Coordinatore dei GLSA </title>
-<author title="Autore">
- <mail link="koon@gentoo.org">Thierry Carrez</mail>
-</author>
-<author title="Autore">
- <mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail>
-</author>
-<author title="Traduzione">
- <mail link="dungeon01@gmail.com">Dungeon01</mail>
-</author>
-
-<abstract>
-Questo documento contiene le procedure, i suggerimenti e soluzioni utili per il coordinatore dei GLSA
-</abstract>
-
-<!-- Il contenuto di questo documento è distribuito sotto licenza CC-BY-SA -->
-<!--Consultare http://creativecommons.org/licenses/by-sa/1.0 -->
-<license/>
-
-<version>0.8.1</version>
-<date>2005-03-07</date>
-
-<chapter>
-<title>Prerequisiti</title>
-<section>
-<title>Accounts</title>
-<body>
-
-<p>
-
-Un determinato numero di accounts deve essere definito prima di lavorare come coordinatore di GLSA.
-Per generare un GLSA dovete ottenere un account <uri link="https://dev.gentoo.org/glsamaker/">GLSAMaker</uri>. Per gestire bugs di sicurezza dovete avere
-un account su <uri link="http://bugs.gentoo.org">Bugzilla</uri>, aggiornato con privilegi di <c>editbugs</c>. Per inviare un GLSA dovete avere un indirizzo vostronome@gentoo.org (in questo caso per essere uno sviluppatore Gentoo).
-Questo indirizzo email dovrà poi essere autorizzato ad inviare messaggi al mailing-group gentoo-announce. Per rendere definitivi degli XML di un GLSA è necessario che al vostro developer account venga abilitata la possibiltà di fare "commit access" verso la GLSA directory nel CVS repository di <c>gentoo</c>.
-Infine avete bisogno di un nick IRC. Sarete tenuti a mostrare il vostro nick nel canale #gentoo-security ogni volta che sarete on-line.
-</p>
-
-<note>
-Tutti i nomi utilizzati dovrebbero essere costanti in modo tale da rendere più semplice l'autenticazione.
-</note>
-
-</body>
-</section>
-<section>
-<title>La chiave GPG </title>
-<body>
-
-<p>
-Dovete ora creare una chiave GPG per il vostro account email vostronome@gentoo.org. Potete generare una chiave specifica o aggiungere l'indirizzo gentoo.org ad una chiave già esistente.
-Il key ID dovrebbe essere inviato a devrelm e dovreste controllare che il vostro nome ed il vostro key ID appaiano nella <uri link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">developer list</uri>. E' molto importante che la chiave venga pubblicata almeno sul keyserver <uri link="http://pgp.mit.edu">pgp.mit.edu</uri> . Può essere pubblicata anche su altri keyservers.
-</p>
-
-</body>
-</section>
-<section>
-<title>Ambiente</title>
-<body>
-
-<p>
-Dovete installare un ambiente CVS sulla vostra macchina locale in modo tale da poter committare i vostri GLSA. Ciò viene reso possibile facendo il checkout di una parte del CVS repository di <c>gentoo</c> verso una directory data.
-(per esempio ~/gentoo_cvs):
-</p>
-
-<pre>
-you@home you $ <i>mkdir gentoo_cvs</i>
-you@home you $ <i>cd gentoo_cvs</i>
-you@home gentoo_cvs $ <i>export CVS_RSH="ssh"</i>
-you@home gentoo_cvs $ <i>export CVSROOT="yourname@cvs.gentoo.org:/var/cvsroot"</i>
-you@home gentoo_cvs $ <i>cvs checkout gentoo/xml/htdocs/security</i>
-</pre>
-
-</body>
-</section>
-<section>
-<title>Sottoscrizioni a Mailing-list </title>
-<body>
-
-<p>
-Per poter postare verso le liste dove pubblicheremo i nostri GLSA, dovete iscrivere il vostro account vostronome@gentoo.org ad esse:
-</p>
-
-<table>
- <tr>
- <th>Lista</th>
- <th>Pagina d'iscrizione</th>
- </tr>
- <tr>
- <ti>bugtraq@securityfocus.com</ti>
- <ti><uri>http://www.securityfocus.com/subscribe</uri></ti>
- </tr>
- <tr>
- <ti>full-disclosure@lists.grok.org.uk</ti>
- <ti><uri>https://lists.grok.org.uk/mailman/listinfo/full-disclosure</uri></ti>
-</tr>
-</table>
-
-<note>
-Potete iscrivervi ad una versione di tipo digest(raccolta) della Full-Disclosure.
-</note>
-
-<p>
-Come sviluppatori di sicurezza verrete aggiunti alla lista gentoo-core e al mailgroup security@gentoo.org.
-Dovreste anche iscrivervi a gentoo-announce, gentoo-dev e gentoo-security.
-</p>
-
-</body>
-</section>
-</chapter>
-<chapter>
-<title>Tipi di bugs di Sicurezza e componenti di Bugzilla</title>
-<section>
-<body>
-
-<p>
-Tutti bugs di sicurezza sono reperibili nel Bugzilla di <c>Gentoo Security</c>.
-Se trovate un bug di sicurezza che ha un nome prodotto errato, per favore correggetelo immediatamente.
-Vi sono differenti tipologie di bugs di sicurezza, e ciascuno ha il proprio componente.
-</p>
-
-</body>
-</section>
-<section>
-<title>Vulnerabilità </title>
-<body>
-
-<p>
-Le vulnerabilità sono bugs di sicurezza relativi all'upstream di un software o bugs introdotti nell'impacchettamento delle ebuilds di Gentoo. Questi bugs risultano nei GLSA. I bugs relativi al kernel hanno la loro propria categoria e non dovrebbero essere archiviati come <c>Vulnerabilità </c>
-</p>
-
-</body>
-</section>
-<section>
-<title>Kernel</title>
-<body>
-
-<p>
-Le vulnerabilità sono trattate utilizzando una procedura a parte. Per distinguerle facilmente dagli altri bugs, esse vengono archiviate sotto la categoria <c>Kernel</c>.
-I bugs relativi al Kernel non risultano nei GLSA ma hanno il proprio meccanismo di pubblicazione (Gentoo KISS).
-</p>
-
-</body>
-</section>
-<section>
-<title>Configurazione di Default </title>
-<body>
-
-<p>
-I pacchetti Gentoo dovrebbero essere di default i più sicuri possibile. I bugs che toccano la default configuration vengono inseriti quando la configurazione di default spedita con il pacchetto può essere migliorata in termini di sicurezza.
-I Bugs relativi alla <c>Configurazione di default</c> non generano alcun GLSA
-</p>
-
-</body>
-</section>
-<section>
-<title>Auditing</title>
-<body>
-
-<p>
-Le Vulnerabilità di Gentoo che vengono rilevate dovrebbero essere controllate più volte prima di uscire all'aperto(verso le liste di upstream o le liste inerenti la sicurezza). Esse vengono archiviate come Bugs confidenziali (Confidential Bugs - si veda qui di seguito) e con il componente <c>Auditing</c>. Quando l'individuazione del bug è stata verificata, questi viene commutato a <c>Vulnerabilità </c>.
-</p>
-
-</body>
-</section>
-<section>
-<title>Bugs di tipo "Restricted"</title>
-<body>
-
-<p>
-A volte un bug ci viene comunicato sotto promessa da parte nostra di mantenerlo segreto fino ad un pubblico rilascio. I bugs limitati hanno la checkbox "Gentoo Security" selezionata, e quindi possono essere raggiunti solo da membri del Gentoo Security Team. Gli attori esterni (maintainer del pacchetto, testers 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 bugs)
-</p>
-
-<p>
-Vi sono tre differenti tipi di bugs "restricted". I primi (e i più segreti) sono i bugs <c>CLASSIFIED</c>. Un bug è definito classified quando contiene informazioni che non dovrebbero mai venir rilasciate. Questo include citazioni di email personali inviate a ristrette mailing-lists o patches intermedie non rese pubbliche. I bugs classificati vengono identificati dalla keyword <c>CLASSIFIED</c>, nella loro Status Whiteboard. Una volta CLASSIFIED, un bug non può tornare allo stato non classificato a meno che almeno due responsabili della sicurezza siano d'accordo nel declassare il suddetto bug. I bugs <c>CLASSIFIED</c> non dovrebbero mai essere aperti(resi cioè "UNRESTRICTED").
-</p>
-
-<p>
-Il secondo tipo di bugs è <c>CONFIDENTIAL</c>. questi sono bugs contenti informazioni che dovrebbero essere tenute segrete fino ad una data di emissione coordinata precedentemente concordata. Nessun aspetto del bug(nome del pacchetto colpito, descrizione, patch proposte e qualsiasi altra cosa) dovrebbe mai uscire allo scoperto. Le patches NON dovrebbero essere committate nel portage CVS.
-</p>
-
-<p>
-Il terzo (e meno segreto) tipo di bugs "Restricted" è dato dai bugs <c>SEMI-PUBLIC</c>.
-I bugs semipubblici dovrebbero restare segreti, ma le patches potrebbero essere committate al portage. Questo accade di solito quando la vulnerabilità non è sconosciuta dalla maggioranza del pubblico ma è accessibile da chiunque(per esempio una patch in upstream sul CVS).
-</p>
-
-</body>
-</section>
-</chapter>
-<chapter>
-<title>Gestione pubblica della vulnerabilità del bug</title>
-<section>
-<title>Regole della "Status Whiteboard"</title>
-<body>
-
-<p>
-Il pannello di stato in Bugzilla ci consente di tener traccia dei passi effettuati verso la risoluzione del bug di sicurezza. Dovrebbe seguire il seguente modello "RATING [status] coordinatore", dove:
-</p>
-
-<table>
-<tr>
-<th>Elemento</th>
-<th>Contenuto</th>
-<th>Esempio</th>
-</tr>
-<tr>
-<ti>RATING</ti>
-<ti>Il rating della vulnerabilità seguendo le correnti policies</ti>
-<ti>B3</ti>
-</tr>
-<tr>
-<ti>[status]</ti>
-<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</ti>
-<ti>koon</ti>
-</tr>
-</table>
-
-<p>
-Sono considerati validi i seguenti tipi di status::
-</p>
-
-<table>
-<tr>
-<th>Status</th>
-<th>Descrizione</th>
-</tr>
-<tr>
-<ti>upstream</ti>
-<ti>In attesa che uno sviluppatore pubblichi in upstream una nuova versione o patch</ti>
-</tr>
-<tr>
-<ti>upstream+</ti>
-<ti>Nessuna risposta dall'upstream</ti>
-</tr>
-<tr>
-<ti>ebuild</ti>
-<ti>In attesa che il maintainer del package di Gentoo fornisca una ebuild corretta</ti>
-</tr>
-<tr>
-<ti>ebuild+</ti>
-<ti>Nessuna risposta ricevuta dal maintainer, riguardo una falla di sicurezza</ti>
-</tr>
-<tr>
-<ti>stable</ti>
-<ti>In attesa che le architetture contrassegnino il package con le keywords appropriate</ti>
-</tr>
-<tr>
-<ti>stable+</ti>
-<ti>Alcuni staff di architettura stanno mettendo troppo tempo per contrassegnare il package in manera appropriata</ti>
-</tr>
-<tr>
-<ti>glsa?</ti>
-<ti>La sicurezza deve decidere se è necessario un GLSA</ti>
-</tr>
-<tr>
-<ti>glsa</ti>
-<ti>In attesa che il coordinatore invii il suo GLSA</ti>
-</tr>
-<tr>
-<ti>glsa+</ti>
-<ti>Il GLSA è in ritardo, ogni coordinatore di GLSA può correggerlo ed inviarlo</ti>
-</tr>
-</table>
-
-<p>
-Le seguenti informazioni addizionali sono ammesse:
-</p>
-
-<table>
-<tr>
-<th>Informazione addizionale</th>
-<th>Descrizione</th>
-<th>Stati Corrispondenti</th>
-</tr>
-<tr>
-<ti>tomask</ti>
-<ti>Quando un package.mask è stato richiesto verso il package</ti>
-<ti>upstream+, ebuild+</ti>
-</tr>
-<tr>
-<ti>masked</ti>
-<ti>se il pagkage era stato segnato "masked" come soluzione temporanea</ti>
-<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</ti>
-<ti>upstream+, ebuild+</ti>
-</tr>
-<tr>
-<ti>blocked</ti>
-<ti>Quando il bug è bloccato da un altro bug</ti>
-<ti>(any)</ti>
-</tr>
-</table>
-
-<p>
-Esempi:
-</p>
-
-<table>
-<tr>
-<ti>C0 [stable]</ti>
-</tr>
-<tr>
-<ti>A3 [ebuild] jaervosz</ti>
-</tr>
-<tr>
-<ti>B1 [stable+ amd64] koon</ti>
-</tr>
-</table>
-
-</body>
-</section>
-<section>
-<title>Determinare lo stato di partenza del bug</title>
-<body>
-
-<p>
-Quando la fix non è disponibile dallo sviluppatore upstream e/o non 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 fix, il bug si trova nello stato [ebuild]. Se la fix è stata inserita nel portage, il bug assume lo stato [stable]. Quando una fix è presente nel portage con tutte le chiavi richieste correttamente configurate, il bug entra in stato [glsa].
-</p>
-
-</body>
-</section>
-<section>
-<title>Stato dei bugs in [upstream] </title>
-<body>
-
-<p>
-Nello stato [upstream], siamo in attesa della pubblicazione di una versione della fix o di una patch decente. Questo stato richiede controlli regolari dell'upstream per informazioni:
-mailing lists di sviluppo e annunci, siti internet, bugs databases, CVS ove possibile, sono tutte fonti importanti d'informazioni. Patches non ufficiali devono essere considerate soltanto se lo sviluppatore upstream non reagisce alla vulnerabilità, e devono essere controllate più volte per assicurarsi che non siano maligne. Quando viene annunciata una nuova versione di una fix, o una nuova patch viene rilasciata, il bug entra nello stato [ebuild]
-</p>
-
-<p>
-Se dall'upstream non v'è reazione nè patch alcuna, entriamo nello stato [upstream+].
-L'unica opzione consiste nell'applicare una security-mask al pachetto vulnerabile e pubblicare un glsa temporaneo se necessario.
-Si veda la policy corrente per ulteriori dettagli inerenti alla procedura d'approvazione del security-masking.
-Il panello di stato dovrebbe quindi essere flaggato con le keyworkds maked e/o tempglsa e la bug severity impostata a <c>enhancement</c>.
-</p>
-
-</body>
-</section>
-<section>
-<title>Bugs in stato [ebuild]</title>
-<body>
-
-<p>
-In stato [ebuild], dobbiamo identificare il maintainer del pacchetto, ed imporgli di generare una fix.
-Le fonti per identificare il gruppo o lo sviluppatore responsabile della manutenzione del pacchetto sono il file metadata.xml, presente nel portage nella directory inerente al pacchetto,
-ed il file Changelog che mostra chi ha effettuato gli ultimi upgrade di versione. Dovreste mettere in cc: il gruppo e/o il maintainer responsabile del pacchetto inerente al bug e chiedere che venga fornita una ebuild per la versione della fix corrente.
-Dovreste controllare periodicamente che una ebuild non sia stata inserita nel portage senza alcuna commento riguardo il bug (a volte accade). Quando l'ebuild appare, il bug entra in stato [stable]
-</p>
-
-<p>
-Se il maintainer non lo rivela, arriviamo allo stato [ebuild+]. In casi di versione di fix, dovreste testare se un semplice salto di versione funziona(basta rinominare l'ebuild all'ultima versione e farne l'emerge). In casi di patch, dovreste testare se si applica in maniera pulita. Allora dovreste trovare un wrangler di bugs di sicurezza con diritti x86 per eseguire il salto di versione e segnare la ebuild ~ per testarla.
- </p>
-
-<p>
-Se il salto di versione non è facile e/o si rileva un problema con la ebuild in questione, l'unica opzione consiste nell'applicare una security-mask al pachetto non mantenuto e pubblicare un glsa temporaneo se necessario.
-Si veda la policy corrente per ulteriori dettagli inerenti alla procedura d'approvazione del security-masking.
-Il panello di stato dovrebbe quindi essere flaggato con le keyworkds maked e/o tempglsa e la bug severity impostata a <c>enhancement</c>.
-</p>
-
-</body>
-</section>
-<section>
-<title>Bugs in stato [stable] </title>
-<body>
-
-<p>
- Nello stato [stable] , dovete determinare di quali chiavi l'ebuild fornita necessita prima che il glsa venga pubblicato. Ciò può essere ingannevole. Dovete considerare ogni versione attualmente presente nel portage in modo che l'ebuild abbia <e>le stesse o più parole "stable"</e> di qualsiasi ogni altro package presente nel portage. Qui v'è un esempio:
-</p>
-
-<table>
-<tr>
-<th>Versioni</th>
-<th>Keywords</th>
-</tr>
-<tr>
-<ti>Affected</ti>
-<ti>x86 ~ppc ~ia64</ti>
-</tr>
-<tr>
-<ti>Affected</ti>
-<ti>x86 ppc</ti>
-</tr>
-<tr>
-<ti>Affected</ti>
-<ti>~x86 ~ppc ~ia64</ti>
-</tr>
-<tr>
-<ti>La Fix deve avere:</ti>
-<th>x86 ppc ~ia64</th>
-</tr>
-</table>
-
-<note>
-Potete usare <uri>http://packages.gentoo.org</uri> per aiutarvi nel determinare le keywords necessarie. Qualora i packages interessati fossero stati rimossi troppo presto dal maintainer del package stesso, dovreste usare l'accesso
-<uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/">CVS </uri> per cercare nell'archivio delle vecchie keywords.
-</note>
-
-<p>
-Una volta determinate (ed inserite come riferimento nel bug) le keywords necessarie, dovreste mettere in Cc: i team di sviluppo delle varie architetture chiedendo loro di contrassegnare l'ebuild come "stable" o ~ di conseguenza.
-Gli alias per le varie architetture sono 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 policy) sono necessarie prima che il bug possa avanzare allo stato [glsa]. Dovreste periodicamente controllare per verificare se vi sono nuove keywords nell'ebuild, dato che talvota queste vengono modificate senza lasciare nessun commento nel bug. Non appena le keywords richieste sono state inserite nel bug per tutte le architetture supportate, il bug entra nello stato [glsa]
-</p>
-
-<p>
-Se i team di sviluppo per le relative architetture impiegano troppo tempo nel testare o cambiare le proprie keywords, o rifiutano di contrassegnare come stable un pacchetto per problemi non ancora risolti, il bug assume lo stato di [stable+].
-Dobbiamo rintracciare i maintainers delle varie architetture affinchè contrassegnino come stable il pacchetto, e diano supporto nel testing dello stesso. Dovreste anche 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 "stable" anche se non è attualmente stabile, come specificato nella policy.
-Se non possono essere rintracciate le keywords, l'unica opzione rimanente è quella di applicare una security-mask al package: non esiste alcuna versione accettabile non affetta dal bug, quindi è come se nessuna fix accettabile sia stata fornita in upstream.
-</p>
-
-</body>
-</section>
-<section>
-<title>Bugs in stato [glsa] </title>
-<body>
-
-<p>
-Nello stato [glsa], il bug di sicurezza è stato corretto. Dobbiamo pubblicare il GLSA o semplicemente chiudere il bug senza GLSA. La policy determina in quali casi un GLSA è necessario e in quali casi non lo è.
-Vi sono anche isituazioni 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 viene pubblicato il GLSA.
-</p>
-
-<p>
- Quando è necessario un GLSA, ma non è stato pubblicato nulla, il bug ebtra 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.
-</p>
-
-</body>
-</section>
-</chapter>
-<chapter>
-<title>Gestione delle vulnerabilità dei bug "confidential" </title>
-<section>
-<title>Regole del pannello di stato(Status Whiteboard) </title>
-<body>
-
-<p>
-I bugs confidenziali dovrebbero seguire questo modello:
-"RATING [status] coordinatore / Data_di_Rilascio CLASSIFIED", dove:
-</p>
-
-<table>
-<tr>
-<th>Elemento</th>
-<th>Contenuto</th>
-<th>Esempio</th>
-</tr>
-<tr>
-<ti>RATING</ti>
-<ti>Il rating della vulnerabilità , facendo riferimento alle correnti policies</ti>
-<ti>B3</ti>
-</tr>
-<tr>
-<ti>[status]</ti>
-<ti>Lo stato effettivo del bug, con informazioni aggiuntive(opzionali</ti>
-<ti>[ebuild+]</ti>
-</tr>
-<tr>
-<ti>coordinator</ti>
-<ti>Il nickname del coordinatore assegnato al bug in questione</ti>
-<ti>koon</ti>
-</tr>
-<tr>
-<ti>Release_date</ti>
-<ti>La data convenuta per la rilevazione coordinata </ti>
-<ti>20050106</ti>
-</tr>
-<tr>
-<ti>CLASSIFIED</ti>
-<ti>Il flag opzionale CLASSIFIED per bugs classificati</ti>
-<ti>CLASSIFIED</ti>
-</tr>
-
-</table>
-
-<p>
-I seguenti stati supplementari sono accettati per i bugs confidenziali:
-</p>
-
-<table>
-<tr>
-<th>Stato</th>
-<th>Descrizione</th>
-</tr>
-<tr>
-<ti>preebuild</ti>
-<ti>Il maintainer del pacchetto specifico è stato chiamato a preparare un'ebuild che non dovrebbe essere inserita nel tree del CVS</ti>
-</tr>
-<tr>
-<ti>prestable</ti>
-<ti>Testers di una specifica architettura sono stati chiamati a testate una ebuild non ancora pubblica</ti>
-</tr>
-</table>
-
-</body>
-</section>
-<section>
-<title>Maneggiare bugs confidenziali</title>
-<body>
-
-<p>
-I bugs semipubblici dovrebbero essere trattati come bugs pubblici, a parte il fatto che nessun gruppo di sviluppo o alias per le varie architetture dovrebbe essere messo in CC tranne gli sviluppatori specifici per quel bug.
-</p>
-
-<p>
-I bugs confidenziali e classificati richiedono maggiore attenzione. L'ebuild e i files per correggere la vulnerabilità NON dovrebbero essere aggiunti al CVS del portage, e nessun aspetto di quei bugs dovrebbe essere discusso in pubblico.
-Patches o tarballs di sovrascrittura del portage possono comunque essere allegati al bug. I testers dovranno installare la propria tarball di sovrascrittura per testarla.
-L'idea con questi bugs è di preparare l'ebuild e farla testare entro la data di rilascio concordata, in modo tale da poterla rilasciare con tutte le keywords necessarie insieme al GLSA nello stesso istante in cui il rilascio dell'ebuild diventa pubblico.
-</p>
-
-</body>
-</section>
-</chapter>
-<chapter>
-<title>Disegnare GLSA con GLSAMaker</title>
-<section>
-<title>Regole Generali</title>
-<body>
-
-<p>
-Il GLSA dovrebbe utilizzare il nome del software colpito prestando attenzione a maiuscole/minuscole, non utilizzando, quindi il package name di Gentoo.
-Per esempio, dovreste utilizzare "MySQl" e non "mysql". I nomi in minuscolo dovrebbero essere utilizzati solo se il software ha un nome tutto in minuscolo o se il software è identificato dal nome del suo comando (ad esempio "traceroute").
-</p>
-
-<p>
-Non dovreste copiare nessuna parte di una descrizione già esistente, ma potete utilizzarle come fonti d'informazione per il GLSA. Se copiate, per esempio una descrizione di un software da un sito internet, per favore utilizzate una citazione e le virgolette.
-</p>
-
-</body>
-</section>
-<section>
-<title>Titolo, Sinossi, Keywords</title>
-<body>
-
-<p>
-Il titolo deve essere corto(< 60 caratteri nella maggior parte dei casi) ed indicare il nome dell'applicazione (non la categoria). Dovrebbe consentire d'indentificare chiaramente la vulnerabilità senza entrare nei dettagli.
-La versione dovrebbe essere omessa, tranne nei rari casi in cui è permesso identificare un pacchetto più chiaramente. I pacchetti multipli colpiti dovrebbero essere separati da una virgola. Gli esempi includono:
-</p>
-
-<table>
-<tr>
-<ti>MySQL: creazione insicura di un file temporaneo</ti>
-</tr>
-<tr>
-<ti>Exim: verify=header_syntax buffer overflow</ti>
-</tr>
-<tr>
-<ti>Apache 1.3: Heap overflow in mod_redirect</ti>
-</tr>
-<tr>
-<ti>MPlayer, xine-lib: Vulnerabilities in RTSP stream handling</ti>
-</tr>
-</table>
-
-<p>
-La sinossi è una corta (< 160 caratteri) ma completa descrizione della vulnerabilità di quale effetto abbia.
-Gli esempi includono:
-</p>
-
-<table>
-<tr>
-<ti>Due utilities MySQL creano files temporanei con paths hardcoded, consentendo ad un attacker di utilizzare un link simbolico per ingannare MySQL nel sovrascrivere dati importanti.</ti>
-</tr>
-<tr>
-<ti>Vulnerabilità multiple, inclusi buffer overflows eseguibili remotamente sono stati rilevati nel codice comune tra Mplayer e la libreria xine</ti>
-</tr>
-</table>
-
-<p>
-La categoria delle keywords GLSA è solitamente impostata a "Ebuild" e dovrebbe contenere il nome del principale software vulnerabile (per esempio "MySQL"). Altri tipi di keyword includono "Portage" (per bugs del portage) e "Infrastructure" (compromissioni dei servers) .
-</p>
-
-</body>
-</section>
-<section>
-<title>Accesso, Severity</title>
-<body>
-
-<p>
-L'accesso dovrebbe essere "Locale" o "Remoto". Le vulnerabilità locali possono essere gestite solo da un utente locale del sistema in questione. Per esempio implica esguire uno script per elevare i privilegi, oppure accedere ad una directory temporanea per far partire un symlink attack. Le vulnerabilità remote sono quelle che possono essere eseguite da un attacker con o senza un account sul sistema bersaglio. Le vulnerabilità remote possono essere sia attive (sfruttando un server in listening per inviare codice maligno) o passive (attirare un utente per collegare il software residente sul client ad un server "maligno" o ad aprire files con codice analogo).
-</p>
-
-<p>
-La severity è un'indicazione di quanto in profondità arrivi la vulnerabilità . Viene definita nella Vulnerability Treatment Policy, nella tabella "Evaluate the vulnerability
-type". Si noti che dipende solo dal massimo rischio, non al fattor comune della configurazione delle opzioni al rischio. Un buffer overflow che consenta l'esecuzione di codice arbitratio in un raro client software, solo quando si utilizza una specifica opzione di configurazione, teoricamente rimane una severità Alta". Un DoS in tutte le configurazioni di Apache teoricamente resta serverità "Normale". In rari casi la severity può essere corretta, quando molti membri del team di sicurezza sono d'accordo, verso un livello più alto. Per esempio, una vulnerabilità che consentisse il deface di un sito internet in Apache ed in tutte le configurazioni dovrebbe probabilmente essere a severity "Alta" piuttosto che "Normale"
-</p>
-
-</body>
-</section>
-<section>
-<title>Packages vulnerabili, inalterati</title>
-<body>
-
-<p>
-Questa sezione fornisce informazioni sulle versioni dei pacchetti che sono rimasti inalterati o vulnerabili alla vulnerabilità descritta nell'informativa corrente.
-Dovreste prestare attenzione particolare a qui numeri, perchè rappresentano una delle poche zone dove ogni errore implica un'errata pubblicazione
-</p>
-
-<p>
-Ci sono diversi campi che compongono il valore di una versione. Il campo contenente il nome del pacchetto deve elencare il nome del pacchetto e la categoria("net-mail/exim"). Riguardo il campo "Architetture", dovreste inserirvi "*" quando la descizione della versione si applica a tutte le architetture contrassegnate nell'ebuild. Dovreste utilizzare entries multiple per architetture differenti se la descrizione della versione è differente di architettura in architettura.
-Il campo "Auto" deve essere impostato a "true" se il paccchetto è aggiornabile via emerge. Per i campi versione possono esservi molteplici casistiche.
-</p>
-
-<impo>
-In questa sezione (e soltanto in questa sezione), le architetture dovrebbero essere scritte così come compaiono nelle keywords(cioè "x86", "amd64", "sparc"...), e non in maiuscolo
-</impo>
-
-<p>
-Il caso più semplice si verifica quando la vulnerabilità è presente in tutte le vecchie versioni ed è corretta in tutte le versioni più recenti rispetto alla versione di una specifica fix. In questo caso, dovreste usare ">= prima versione corretta" come inalterata e "<= ultima versione colpita" come vulnerabile. Dovreste controllare più volte che non esista un'ebuild fra l'ultima versione colpita e la prima versione corretta. Qualora vi trovaste in dubbio, dovreste usare ">= prima versione corretta" come inalterata e "<= prima versione corretta" come vulnerabile.
-</p>
-
-<p>
-Un caso più complesso si verifica quando la vulnerabilità si presenta soltanto in alcune versioni recenti. Facciamo l'esempio di un pacchetto dove la versione 1.2.8-r2 non è stata colpita,le versioni 1,2,9, 1.2.9-r1 e 1.2.9-r2 sono state colpite e la versione 1,2,10 è stata corretta. In questo caso ci sono due possibilità.
-</p>
-
-<table>
-<tr>
-<th>Inalterata</th>
-<th>Vulnerabile</th>
-</tr>
-<tr>
-<ti>>=1.2.10</ti>
-<ti>==1.2.9 ==1.2.9-r1 ==1.2.9-r2</ti>
-</tr>
-<tr>
-<ti><=1.2.8-r2 >=1.2.10</ti>
-<ti><1.2.10</ti>
-</tr>
-</table>
-
-<p>
-Per concludere, quando il pacchetto non ha una versione corretta, dovreste omettere l'opzione "inalterato" (unaffected) per quel pacchetto ed impostare "Auto" a "no".
-</p>
-
-<impo>
-Quando le versioni delle fix sono complesse, dovreste controllare più volte che le versioni XML e TXT del GLSA elenchino correttamente le vostre versioni
-</impo>
-
-</body>
-</section>
-<section>
-<title>Background, Descrizione, Impatto</title>
-<body>
-
-<p>
-La sezione Background fornisce le informazioni sul pacchetto a rischio. Descrive brevemente cos'è e fornisce tutte le informazioni utili a comprendere la parte del pacchetto vulnerabile. La sezione Background dovrebbe essere più corta della sezione di descrizione o della sezione impatto (Impact). Tra gli esempi da seguire includiamo:
-</p>
-
-<table>
-<tr>
-<ti>Il K Desktop Environement (KDE) è un potente ambiente grafico desktop della Free Software foundation. KDE usa gli URI handlers per innescare vari programmi quando vengono ricevute delle URL specifiche.</ti>
-</tr>
-<tr>
-<ti>
-CVS (Concurrent Versions System) è un sistema open-source di controllo di versione network-transparent. Contiene sia una client utility che un server.</ti>
-</tr>
-<tr>
-<ti>Metamail è un programma che decodifica la posta codificata MIME. Viene quindi spesso automaticamente invocato quando una email viene letta o ricevuta.</ti>
-</tr>
-</table>
-
-<p>
-La sezione "descrizione" descrive più in dettaglio qual è la vulnerabilità senza dire a che cosa accade quando questa viene sfruttata. Dovrebbe essere comprensibile da persone senza grandissime basi di sicurezza. A volte non si trovano affatto le informazioni sulla vulnerabilità, in questi casi dovreste lasciare la descrizione breve.Tra i buoni esempi includiamo:
-</p>
-
-<table>
-<tr>
-
-<ti>
-Il Telnet URI handler in Opera non controlla l'esistenza di caratteri '- ' iniziali nell'hostname. Di conseguenza, un link maligno del tipo telnet:// potrebbe essere capace di passare opzioni al telnet stesso. Un esempio sarebbe "telnet://-nMyFile". Se MyFile esiste nella home directory dell'utente e l'utente che clicca sul link ha i permessi di scrittura su di esso, i contenuti del file saranno sovrescritti con'output delle informazioni del telnet trace. Se MyFile non esiste, il file verrà generato nella home directory dell'utente.</ti>
-</tr>
-<tr>
-<ti>
-L'utility di bug reporting di MySQL(mysqlbug) genera un file temporaneo per loggarvi i bug reports. Un utente locale "maligno" con diritti di scrittura su /tmp potrebbe generare un link simbolico dal nome mysqlbug-N puntante ad un file protetto, come /etc/passwd, in modo tale che qualora mysqlbug generasse l'ennesimo file di log, finirebbe con il sovrascrivere l'obiettivo(nel nostro esempio, /etc/passwd). Una vulnerabilità simile esiste con la mysql_multi ultility, che genera una file temporaneo denominato mysql_multi.log
-</ti>
-</tr>
-<tr>
-<ti>Vulnerabilità multiple sono state scovate e riparate nell'RTSP che gestisce il codice in comune alle versioni recenti di questi due pacchetti. Queste vulnerabilità includono parecchi buffer overflows sfruttabili da remoto.</ti>
-</tr>
-</table>
-
-<p>
-La sezione "Impact" descrive l'effetto globale delle vulnerabilità descritte nella sezione "descrizione", una volta sfruttate. Dovrebbe focalizzarsi sul massimo rischio possibile.
-Buoni esempi sono:
-</p>
-
-<table>
-<tr>
-<ti>
-Un attacker remoto, presentandosi come RTSP stream server, può eseguire codice arbitrariamente con i diritti dell'utente del software che sta eseguendo lo stream(MPlayer o qualsiasi altro player che utilizzi xine/xine-lib). Un altro attacker può attirare un utente per usare un URL "maligna" o una playlist per ottenere lo stesso identico risultato</ti>
-</tr>
-<tr>
-<ti>
-Questo exploit ha due possibili effetti. In primo luogo, può generare nuovi files nella home directory dell'utente. In secondo luogo, e molto più pericoloso, può sovrascrivere i files esistenti per i quali l'utente ha i permessi di scrittura. Un attacker con una certa conoscenza della home directory dell'utente potrebbe essere in grado di distruggere files importanti salvati in quella directory.</ti>
-</tr>
-</table>
-
-</body>
-</section>
-<section>
-<title>Workaround, Soluzione</title>
-<body>
-
-<p>
-Il workaround descrive se esiste un qualsiasi maniera semplice (tranne l'aggiornamento alla versione di fix) per evitare di essere vittime della vulnerabilità. I buoni esempi includono:
-</p>
-
-<table>
-<tr>
-<ti>
-Come workaround provvisorio, bypassando il supporto del Kerberos 4, potreste spegnere il kadmin del Kerberos 4 facendo partire il kadmind con l'opzione -- no-kerberos4.</ti>
-</tr>
-<tr>
-<ti>Ad oggi non esistono workaround conosciuti.</ti>
-</tr>
-</table>
-
-<p>
-La sezione "Risoluzione" spiega nei termini human-readable che cosa dovete fare per completamente essere protetti dalla vulnerabilità. Questa sezione deve assomigliare a questa:
-</p>
-
-<pre>
-Tutti gli utenti di Heimdal dovrebbero effettuare l'upgrade all'ultima versione stabile:
-<code>
-# emerge sync
-
-# emerge -pv ">=app-crypt/heimdal-0.6.2"
-# emerge ">=app-crypt/heimdal-0.6.2"</code>
-</pre>
-
-<p>
-Qualora vi fossero più architetture, dovrebbe assomigliare a questa
-</p>
-
-<pre>
-Gli utenti di OpenOffice.org su SPARC dovrebbero:
-<code>
-# emerge sync
-
-# emerge -pv "<=app-office/openoffice-1.1.0-r3"
-# emerge "<=app-office/openoffice-1.1.0-r3"
-</code>
-</p>
-<p>
-
-Gli utenti di OpenOffice.org su PPC dovrebbero:
-</p>
-<code>
-# emerge sync
-
-# emerge -pv ">=app-office/openoffice-1.0.3-r1"
-# emerge ">=app-office/openoffice-1.0.3-r1"</code>
-</pre>
-
-<p>
-Se il GLSA riguarda una libreria condivisa, dovreste includere il seguente paragrafo all'estremità della sezione "risoluzione" per avvisare circa la necessità di effettuare la rebuild degli eseguibili collegati.
-</p>
-
-<table>
-<tr>
-<ti>I pacchetti che dipendono da questa libreria possono avere bisogno di essere ricompilati. Tools come revdep-rebuild possono aiutare nell'identificare alcuni dei questi pacchetti.</ti>
-</tr>
-</table>
-
-</body>
-</section>
-<section>
-<title>Riferimenti</title>
-<body>
-
-<p>
-La sezione "Riferimenti" dovrebbe fornire i links alle informazioni di riferimento sulla vulnerabilità in questione. Quando un numero CVE (CAN-xxxx-xxx) è disponibile, dovrebbe essere fornito (con il numero CAN completo in "Title"). Potete anche collegare uno advisory di uno sviluppatore upstream e/o un'email announce, quando disponibili. Dovreste evitare links ad advisories di altre distribuzioni o advisories non ufficiali provenienti da entità esterne.
-</p>
-
-</body>
-</section>
-</chapter>
-<chapter>
-<title>Pubblicazione GLSA </title>
-<section>
-<title>Peer reviewing</title>
-<body>
-
-<p>
-Quando la bozza iniziale è pronta, deve essere sottoposta alla revisione degli altri membri del team di sicurezza, effettuando una richiesta di revisione sul canale #gentoo-security. La versione finale (dopo che tutte le correzioni sono state applicate) deve essere approvata da due membri del team di sicurezza prima di essere committata e spedita.
-</p>
-
-<p>
-Nel rivedere la bozza di un GLSA, controllare con attenzione le seguenti cose:
-</p>
-
-<ul>
-<li>
-Versoni colpite/inalterate (Controllare nel Changelog che le versioni siano corrette e assicurarsi che non vi siano versioni che non siano definite o colpite o inalterate ).
-</li>
-<li>Correttezza del titolo.</li>
-<li>
- Severity ed accesso (Non fate solo riferimento al rating del bug e se è necessario un account locale o remoto per un accesso "local o remote" ).</li> <li>Alla fine viene effettuato un sanity check: si verifica che sia veramente una vulnerabilità e non un semplice bug (come le non-vulnerabilities di samba e shadow)
-</li>
-</ul>
-<p>
-Quando la bozza viene approvata, deve esserle assegnato un numero ufficiale GLSA. Ciò viene fatto chiamando la funzione "Move" in GLSAMaker per spostare la bozza dalla zona di sviluppo alla zona ufficiale.
-</p>
-
-</body>
-</section>
-<section>
-<title>GLSA XML commit</title>
-<body>
-
-<p>
-Dovete commettere il GLSA XML al tree del CVS di Gentoo in modo che compaia automaticamente nell'handling del feed RDF, nella lista dei GLSA e negli aggiornamenti del portage. Dovreste in primo luogo aggiornare la vostra directory GLSA nel tree del gentoo CVS repository:
-</p>
-
-<pre>
-you@home you $ <i>cd gentoo_cvs</i>
-you@home gentoo_cvs $ <i>cvs update -dP gentoo/xml/htdocs/security</i>
-</pre>
-
-<p>
-
-A questo punto dovreste cliccare<c>Fetch</c> nel GLSA per scaricare la versione XML,
-e salvarla nella vostra gentoo_cvs/gentoo/xml/htdocs/security/en/glsa/
-directory. A questo punto dovreste committare ed aggiungere il file XML :
-</p>
-
-<pre>
-you@home gentoo_cvs $ <i>cd gentoo/xml/htdocs/security/en/glsa</i>
-you@home glsa $ <i>cvs add glsa-YYYYMM-NN.xml</i>
-you@home glsa $ <i>cvs commit -m "GLSA YYYYMM-NN" glsa-YYYYMM-NN.xml</i>
-</pre>
-
-</body>
-</section>
-<section>
-<title>E-mail announcement</title>
-<body>
-
-<warn>
-Ogni volta che usate un nuovo setup (software o macchina) per inviare un annuncio GLSA, dovreste far sì che il vostro setup venga controllato, inviando un'email di test ad un altro membro del team di sicurezza.
-</warn>
-
-<p>
-Cliccare su Txt download per ottenere una versione di testo del GLSA. Controllare che la sezione colpite/inalterate (affected/unaffected) sembri a posto, quindi preparare una mail con le seguenti regole:
-</p>
-
-<ul>
-<li><b>Da </b> e<b>Indirizzo di Ritorno</b> devono essere impostati a vostronome@gentoo.org</li>
-<li><b>To</b> e<b>Cc</b> dovrebbero essere configurati secondo policy</li>
-<li><b>Oggetto</b> deve essere "[ GLSA XXXXYY-ZZ ] la vostra vulnerabilità qui"
- (dovreste copiare/incollare dal titolo nel file di testo)</li>
-<li>Il corpo della mail dovrebbe corrispondere al contenuto del file di testo, dalla header
-"Gentoo Linux Security Advisory" alla fine del file</li>
-<li>L'email deve essere firmata dalla chiave GPG per l'indirizzo vostronome@gentoo.org </li>
-</ul>
-
-<note>
-Riceverete un'email di ritorno da gentoo-announce dicendo che è richiesta moderazione. Basta rispondere a questa mail e l'email announce precedentemente detto arriverà a destinazione.
-</note>
-
-</body>
-</section>
-<section>
-<title>Chiusura dei bug</title>
-<body>
-
-<p>
-Dovreste controllare che la mail sia arrivata a gentoo-announce, poi potete chiudere il bug(s) relativo, regolando la condizione a <b>RESOLVED/FIXED</b>, con un commento indicante numero GLSA
-</p>
-
-</body>
-</section>
-<section>
-<title>Pubblicazione Errata/Aggiornamenti</title>
-<body>
-
-<p>
-Un errata viene pubblicato quando viene commesso un errore, altrimenti stiamo parlando di un aggiornamento. Quando la policy garantisce una ripubblicazione dovrebbero essere seguite queste linee guida:
-</p>
-
-<ul>
-<li>
-Il campo revisione dovrebbe essere correttamente impostato in XML. Ciò significa che la revisione potrebbe avere bisogno di di essere corretta manualmente nella directory data di GLSAMaker, se fate cambiamenti multipli usando GLSAMaker ( es. <revised>September 10, 2004: 02</revised>)</li>
-<li>Se non sussiste vulnerabilità nessun pacchetto colpito dovrebbe essere elencato nell'XML</li>
-<li>Il titolo può cambiare( es. GLSA 200409-14 per Samba e GLSA 200411-01 per ppp)
-</li>
-<li>Non tutti gli Errata richiedono ripubblicazione. La policy spiega dettagliatamente quando la ripubblicazione è necessaria.</li>
-<li>
-Per la versione di testo GLSAmaker può aggiungere le informazioni relative agli aggiornamenti ed alle errata. Si seguano manualmente le istruzioni fornite da GLSAmaker.</li>
-<li>
-La versione testuale deve contenere la sezione degli aggiornamenti o delle errata (si veda l'esempio indicato sotto) e soltanto DOPO QUESTO solo sezioni vengono cambiate (la versione XML non ha sezioni aggiuntive)</li>
-</ul>
-
-<table>
-<tr>
-<ti>
-Questo advisory è stato descritto via ppp in maniera non corretta come vulnerabile ad un DoS. Dopo ulteriori verifiche, sembra che un utente remoto possa negare soltanto il servizio a sè stesso, quindi questo bug non induce alcun problema di sicurezza. Le sezioni corrette compaiono qui sotto.</ti>
-</tr>
-</table>
-
-<p>
- Ecco due esempi completi di errata email, si veda<uri
- link="http://archives.gentoo.org/ml/gentoo-announce/2004/09/msg_00015.xml">ERRATA:
- [ GLSA 200409-14 ] Samba: Remote printing non-vulnerability</uri>
- (dove non c'era nessuna vulnerabilità) e <uri
- link="http://archives.gentoo.org/ml/gentoo-announce/2004/06/msg_00000.xml">ERRATA:
- [ GLSA 200405-25 ] Tla: Multiple vulnerabilities in included
- libneon</uri> (dove il problema non era stato corretto in maniera efficace nella versione iniziale). Per un esempio di update, si veda <uri
- link="http://archives.gentoo.org/ml/gentoo-announce/2004/10/msg_00029.xml">UPDATE:
- [ GLSA 200410-30 ] GPdf, KPDF, KOffice: Vulnerabilities in included
- xpdf</uri> (dove la fix ha introdotto un'altra vulnerabilità ).
-</p>
-
-<p>
-Altrimenti dovrebbero essere seguite le linee guida standard GLSA.
-</p>
-
-</body>
-</section>
-</chapter>
-<chapter>
-<title>GLSA Coordinators Tools</title>
-<section>
-<title>Gathering delle Informazioni </title>
-<body>
-
-<ul>
-<li><uri link="http://dev.gentoo.org/~koon/packageview/">packageview</uri>
- è un tool che aprirà packages.gentoo.org e Gentoo ViewCVS
- nel punto giusto per una categoria e una nome pacchetto assegnati. Aiuta a determinare quali
- keywords sono richieste per tracciare i cambiamenti di un pacchetto..</li>
-</ul>
-
-</body>
-</section>
-<section>
-<title>GLSA guide per la pubblicazione</title>
-<body>
-
-<ul>
-<li><uri link="http://dev.gentoo.org/~koon/glsacommit.txt">glsacommit</uri>
- è una funzione bash che si occupa l'handling GLSA committing. Caratterizzato dall'ssh-agent keyadding,
- glsa-check controlla più volte la conformità ed ha delle "Are you sure" funzioni.
- Editatelo per soddisfare le vostre necessità e le posizioni delle directory .</li>
-</ul>
-
-</body>
-</section>
-</chapter>
-</guide>
-
+<?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.4 2007/11/11 22:02:22 scen Exp $ -->
+
+<guide link="/security/it/coordinator_guide.xml" lang="it">
+<title>Guida per il Coordinatore dei GLSA</title>
+
+<author title="Autore">
+ <mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+<author title="Autore">
+ <mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail>
+</author>
+<author title="Traduzione">
+ <mail link="dungeon01@gmail.com">Dungeon01</mail>
+</author>
+<author title="Traduzione">
+ <mail link="luigi.mantellini@gmail.com">Luigi Mantellini</mail>
+</author>
+
+<abstract>
+Questo documento contiene le procedure, i suggerimenti e soluzioni utili per il
+coordinatore dei GLSA
+</abstract>
+
+<!-- Il contenuto di questo documento è distribuito sotto licenza CC-BY-SA -->
+<!--Consultare http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>0.8.4</version>
+<date>2007-01-24</date>
+
+<chapter>
+<title>Prerequisiti</title>
+<section>
+<title>Account</title>
+<body>
+
+<p>
+Deve essere definito un determinato numero di account prima di lavorare come
+coordinatore di GLSA. Per generare un GLSA è necessario ottenere un account <uri
+link="https://dev.gentoo.org/glsamaker/">GLSAMaker</uri>. Per gestire bug di
+sicurezza bisogna avere un account su <uri
+link="http://bugs.gentoo.org">Bugzilla</uri>, aggiornato con privilegi di
+<c>editbugs</c>. Per poter inviare un GLSA bisogna avere un indirizzo del tipo
+tuonome@gentoo.org (in questo caso per essere uno sviluppatore Gentoo). Questo
+indirizzo email dovrà poi essere autorizzato ad inviare messaggi al
+mailing-group gentoo-announce. Per rendere definitivi degli XML di un GLSA è
+necessario che al proprio account di sviluppatore sia abilitata la possibilità
+di poter eseguire "commit access" verso la directory GLSA nel CVS repository di
+<c>Gentoo</c>. Infine è necessario un nick IRC. Gli sviluppatori Gentoo sono
+tenuti a mostrare il proprio nick nel canale #gentoo-security ogni qual volta
+siano on-line.
+</p>
+
+<note>
+Tutti i nomi utilizzati dovrebbero essere costanti in modo tale da rendere più
+semplice l'autenticazione.
+</note>
+
+</body>
+</section>
+<section>
+<title>La chiave GPG</title>
+<body>
+
+<p>
+A questo punto bisogna creare una chiave GPG per il proprio account email
+tuonome@gentoo.org. È possibile generare una chiave specifica o aggiungere
+l'indirizzo @gentoo.org ad una chiave già esistente. Successivamente si
+dovrà inviare il proprio key ID al team "devrel" (Relazioni tra Sviluppatori,
+ndt), controllando inoltre che il proprio nome e lo key ID appaiano nell'<uri
+link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">elenco
+degli sviluppatori</uri>. È molto importante che la chiave venga pubblicata
+almeno sul server delle chiavi <uri
+link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri>, tuttavia la si può
+pubblicare anche su altri.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ambiente</title>
+<body>
+
+<p>
+Bisogna installare un ambiente CVS sulla propria macchina locale in modo tale da
+poter effettuare i commit dei propri GLSA. Ciò viene reso possibile eseguendo il
+checkout di una parte del CVS repository di <c>Gentoo</c> verso una directory
+data. (per esempio ~/gentoo_cvs):
+</p>
+
+<pre caption="Configurazione ambiente CVS">
+you@home you $ <i>mkdir gentoo_cvs</i>
+you@home you $ <i>cd gentoo_cvs</i>
+you@home gentoo_cvs $ <i>export CVS_RSH="ssh"</i>
+you@home gentoo_cvs $ <i>export CVSROOT="yourname@cvs.gentoo.org:/var/cvsroot"</i>
+you@home gentoo_cvs $ <i>cvs checkout gentoo/xml/htdocs/security</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Sottoscrizioni a Mailing-list</title>
+<body>
+
+<p>
+Per poter inviare messaggi verso le liste dove saranno pubblicate le GLSA,
+bisogna iscrivere il proprio account tuonome@gentoo.org ad esse:
+</p>
+
+<table>
+<tr>
+ <th>Lista</th>
+ <th>Pagina d'iscrizione</th>
+</tr>
+<tr>
+ <ti>bugtraq@securityfocus.com</ti>
+ <ti><uri>http://www.securityfocus.com/subscribe</uri></ti>
+</tr>
+<tr>
+ <ti>full-disclosure@lists.grok.org.uk</ti>
+ <ti>
+ <uri>https://lists.grok.org.uk/mailman/listinfo/full-disclosure</uri>
+ </ti>
+</tr>
+</table>
+
+<note>
+Ci si può iscrivere ad una versione di tipo digest (raccolta) della
+Full-Disclosure.
+</note>
+
+<p>
+Come sviluppatori di sicurezza si verrà aggiunti alla lista gentoo-core e al
+mailgroup security@gentoo.org. È consigliabile iscriversi anche a
+gentoo-announce, gentoo-dev e gentoo-security.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Tipi di bug di Sicurezza e componenti di Bugzilla</title>
+<section>
+<body>
+
+<p>
+Tutti bug di sicurezza sono reperibili nella categoria <c>Gentoo Security</c> di
+Bugzilla. Se si individua un bug di sicurezza che ha un nome di categoria errato,
+si prega di correggerlo immediatamente. Vi sono differenti tipologie di bug di
+sicurezza, e ciascuno ha il proprio componente.
+</p>
+
+</body>
+</section>
+<section>
+<title>Vulnerabilità</title>
+<body>
+
+<p>
+Le vulnerabilità sono bug di sicurezza relativi alla versione originaria di un
+software o bug introdotti nell'impacchettamento degli ebuild di Gentoo. Questi
+bug sono riportati nei GLSA. I bug relativi al kernel hanno la loro propria
+categoria e non dovrebbero essere archiviati come <c>Vulnerabilità</c>
+(vulnerability).
+</p>
+
+</body>
+</section>
+<section>
+<title>Kernel</title>
+<body>
+
+<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).
+</p>
+
+</body>
+</section>
+<section>
+<title>Configurazione Predefinita</title>
+<body>
+
+<p>
+I pacchetti Gentoo dovrebbero avere le impostazioni predefinite più sicure
+possibile. I bug che toccano le configurazioni predefinite sono inseriti
+quando tali configurazioni, fornita con il pacchetto, possono essere migliorate
+in termini di sicurezza. I bug relativi alla <c>Configurazione Predefinita</c>
+non generano alcun GLSA.
+</p>
+
+</body>
+</section>
+<section>
+<title>Auditing</title>
+<body>
+
+<p>
+Le Vulnerabilità rilevate dagli sviluppatori di Gentoo dovrebbero essere
+controllate più volte prima di essere rese note (verso le liste degli
+sviluppatori originali del software o le liste inerenti la sicurezza). Esse
+vengono archiviate come bug confidenziali (Confidential Bugs - si veda qui di
+seguito) e con il componente <c>Auditing</c>. Quando l'individuazione del bug è
+stata verificata, questo viene commutato a <c>Vulnerabilità</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bug di tipo "Restricted"</title>
+<body>
+
+<p>
+A volte un bug viene comunicato al Team di Sicurezza di Gentoo sotto promessa
+di quest'ultimo di mantenerlo segreto fino ad un pubblico rilascio. 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, come il manutentore del pacchetto od 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).
+</p>
+
+<p>
+Vi sono tre differenti tipi di bug "restricted" (con limitazioni. ndt). I primi
+(e i più segreti) sono i bug <c>CLASSIFIED</c> (classificato, ndt). Un bug è
+definito classified quando contiene informazioni che non dovrebbero mai venir
+rilasciate. Questo include citazioni di email personali inviate a mailing-list
+ristrette o patch intermedie non rese pubbliche. I bug classificati vengono
+identificati dalla keyword <c>CLASSIFIED</c>, nella loro Status Whiteboard. Una
+volta CLASSIFIED, un bug non può tornare allo stato non classificato a meno che
+almeno due responsabili della sicurezza siano d'accordo nel declassare il
+suddetto bug. I bug <c>CLASSIFIED</c> non dovrebbero mai essere aperti (resi
+cioè "UNRESTRICTED").
+</p>
+
+<p>
+Il secondo tipo di bug è <c>CONFIDENTIAL</c>. questi sono bug contenenti
+informazioni che dovrebbero essere tenute segrete fino ad una data di emissione
+coordinata precedentemente concordata. Nessun aspetto del bug (nome del
+pacchetto colpito, descrizione, patch proposte e qualsiasi altra cosa) dovrebbe
+mai uscire allo scoperto. Le patch NON dovrebbero essere inserite nel CVS
+di portage.
+</p>
+
+<p>
+Il terzo (e meno segreto) tipo di bug "Restricted" è dato dai bug
+<c>SEMI-PUBLIC</c> (semipubblico, ndt). I bug semipubblici dovrebbero restare
+segreti, ma le patch potrebbero essere inserite in portage. Questo accade di
+solito quando la vulnerabilità non è sconosciuta dalla maggioranza del
+pubblico ma è accessibile da chiunque (per esempio una patch sul CVS originale
+del software).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gestione pubblica della vulnerabilità del bug</title>
+<section>
+<title>Regole della "Status Whiteboard"</title>
+<body>
+
+<p>
+Il pannello di stato in Bugzilla consente al team di Sicurezza di tener traccia
+dei passi effettuati verso la risoluzione del bug di sicurezza. Dovrebbe seguire
+il seguente modello "RATING [status] coordinatore", dove:
+</p>
+
+<table>
+<tr>
+ <th>Elemento</th>
+ <th>Contenuto</th>
+ <th>Esempio</th>
+</tr>
+<tr>
+ <ti>RATING</ti>
+ <ti>
+ Il rating della vulnerabilità, in base alle regole di politica correnti
+ </ti>
+ <ti>B3</ti>
+</tr>
+<tr>
+ <ti>[status]</ti>
+ <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</ti>
+ <ti>koon</ti>
+</tr>
+</table>
+
+<p>
+Sono considerati validi i seguenti tipi di status:
+</p>
+
+<table>
+<tr>
+ <th>Status</th>
+ <th>Descrizione</th>
+</tr>
+<tr>
+ <ti>upstream</ti>
+ <ti>
+ In attesa che uno sviluppatore pubblichi in "upstream" (provenienza
+ originale del software, ndt) una nuova versione o patch
+ </ti>
+</tr>
+<tr>
+ <ti>upstream+</ti>
+ <ti>
+ Nessuna risposta dagli sviluppatori originali del software ("upstream")
+ </ti>
+</tr>
+<tr>
+ <ti>ebuild</ti>
+ <ti>
+ In attesa che il mantenitore del pacchetto di Gentoo fornisca un ebuild
+ corretto
+ </ti>
+</tr>
+<tr>
+ <ti>ebuild+</ti>
+ <ti>
+ Nessuna risposta ricevuta dal mantenitore, si prende in considerazione un
+ aggiornamento di sicurezza
+ </ti>
+</tr>
+<tr>
+ <ti>stable</ti>
+ <ti>
+ In attesa che le architetture contrassegnino il pacchetto con le keyword
+ appropriate
+ </ti>
+</tr>
+<tr>
+ <ti>stable+</ti>
+ <ti>
+ Alcuni team di architettura stanno impiegando troppo tempo per
+ contrassegnare il pacchetto in manera appropriata
+ </ti>
+</tr>
+<tr>
+ <ti>glsa?</ti>
+ <ti>Il team di sicurezza deve decidere se è necessario un GLSA</ti>
+</tr>
+<tr>
+ <ti>glsa</ti>
+ <ti>In attesa che il coordinatore invii il suo GLSA</ti>
+</tr>
+<tr>
+ <ti>glsa+</ti>
+ <ti>
+ Il GLSA è in ritardo, ogni coordinatore di GLSA può correggerlo ed inviarlo
+ </ti>
+</tr>
+</table>
+
+<p>
+Sono ammesse le seguenti informazioni aggiuntive:
+</p>
+
+<table>
+<tr>
+ <th>Informazione aggiuntiva</th>
+ <th>Descrizione</th>
+ <th>Stati Corrispondenti</th>
+</tr>
+<tr>
+ <ti>tomask</ti>
+ <ti>Quando un package.mask è stato richiesto verso il pacchetto</ti>
+ <ti>upstream+, ebuild+</ti>
+</tr>
+<tr>
+ <ti>masked</ti>
+ <ti>se il pacchetto era stato segnato "masked" come soluzione temporanea</ti>
+ <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
+ </ti>
+ <ti>upstream+, ebuild+</ti>
+</tr>
+<tr>
+ <ti>blocked</ti>
+ <ti>Quando il bug è bloccato da un altro bug</ti>
+ <ti>(qualsiasi)</ti>
+</tr>
+</table>
+
+<p>
+Esempi:
+</p>
+
+<table>
+<tr>
+ <ti>C0 [stable]</ti>
+</tr>
+<tr>
+ <ti>A3 [ebuild] jaervosz</ti>
+</tr>
+<tr>
+ <ti>B1 [stable+ amd64] koon</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Determinare lo stato di partenza del bug</title>
+<body>
+
+<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].
+</p>
+
+</body>
+</section>
+<section>
+<title>Stato dei bug in [upstream]</title>
+<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
+degli sviluppatori originali per informazioni: mailing list di sviluppo e
+annunci, siti internet, database di bug database, CVS 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].
+</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
+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
+quindi essere flaggato con le keyword masked e/o tempglsa e la severità del bug
+impostata ad <c>enhancement</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bug in stato [ebuild]</title>
+<body>
+
+<p>
+In stato [ebuild], 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
+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]
+</p>
+
+<p>
+Se il manutentore non lo rivela, si arriva allo stato [ebuild+]. In casi di
+versione correttiva, testare se un semplice incremento di versione funziona
+(basta rinominare l'ebuild all'ultima versione e farne l'emerge). In casi di
+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 testarlo.
+</p>
+
+<p>
+Se l'incremento di versione non è facile e/o si rileva un problema con l'ebuild
+in questione, l'unica opzione consiste nell'applicare una security-mask al
+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
+<c>enhancement</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bug in stato [stable] </title>
+<body>
+
+<p>
+Nello stato [stable], 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
+pacchetto presente nel portage. Ecco un esempio:
+</p>
+
+<table>
+<tr>
+ <th>Versioni</th>
+ <th>Keyword</th>
+</tr>
+<tr>
+ <ti>Influenzate</ti>
+ <ti>x86 ~ppc ~ia64</ti>
+</tr>
+<tr>
+ <ti>Influenzate</ti>
+ <ti>x86 ppc</ti>
+</tr>
+<tr>
+ <ti>Influenzate</ti>
+ <ti>~x86 ~ppc ~ia64</ti>
+</tr>
+<tr>
+ <ti>La correzione deve avere:</ti>
+ <th>x86 ppc ~ia64</th>
+</tr>
+</table>
+
+<note>
+È 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
+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. 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
+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
+stato [glsa].
+</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
+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
+"stable" anche se non è attualmente stabile, come specificato nel regolamento.
+Se non possono essere rintracciate le keyword, l'unica opzione rimanente è
+quella di applicare una security-mask al pacchetto: non esiste alcuna versione
+accettabile non affetta dal bug, quindi è come se nessuna correzione accettabile
+sia stata fornita nel ramo di sviluppo originale.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bug in stato [glsa]</title>
+<body>
+
+<p>
+Nello stato [glsa], 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
+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.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gestione delle vulnerabilità dei bug "confidential"</title>
+<section>
+<title>Regole del pannello di stato (Status Whiteboard)</title>
+<body>
+
+<p>
+I bug confidenziali dovrebbero seguire questo modello: "RATING [status]
+coordinatore / Data_di_Rilascio CLASSIFIED", dove:
+</p>
+
+<table>
+<tr>
+ <th>Elemento</th>
+ <th>Contenuto</th>
+ <th>Esempio</th>
+</tr>
+<tr>
+ <ti>RATING</ti>
+ <ti>
+ Il rating della vulnerabilità, facendo riferimento alle politiche correnti
+ </ti>
+ <ti>B3</ti>
+</tr>
+<tr>
+ <ti>[status]</ti>
+ <ti>Lo stato effettivo del bug, con informazioni aggiuntive(opzionali</ti>
+ <ti>[ebuild+]</ti>
+</tr>
+<tr>
+ <ti>coordinator</ti>
+ <ti>Il nickname del coordinatore assegnato al bug in questione</ti>
+ <ti>koon</ti>
+</tr>
+<tr>
+ <ti>Release_date</ti>
+ <ti>La data convenuta per la rilevazione coordinata</ti>
+ <ti>20050106</ti>
+</tr>
+<tr>
+ <ti>CLASSIFIED</ti>
+ <ti>Il flag opzionale CLASSIFIED per bug classificati</ti>
+ <ti>CLASSIFIED</ti>
+</tr>
+
+</table>
+
+<p>
+I seguenti stati supplementari sono accettati per i bug confidenziali:
+</p>
+
+<table>
+<tr>
+ <th>Stato</th>
+ <th>Descrizione</th>
+</tr>
+<tr>
+ <ti>preebuild</ti>
+ <ti>
+ Il mantenitore del pacchetto specifico è stato chiamato a preparare
+ un'ebuild che non dovrebbe essere inserita nel tree del CVS
+ </ti>
+</tr>
+<tr>
+ <ti>prestable</ti>
+ <ti>
+ I collaudatori di una specifica architettura sono stati chiamati a testare
+ un ebuild non ancora pubblico
+ </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Maneggiare bug confidenziali</title>
+<body>
+
+<p>
+I bug semipubblici dovrebbero essere trattati come bug pubblici, a parte il
+fatto che nessun gruppo di sviluppo o alias per le varie architetture dovrebbe
+essere messo in CC tranne gli sviluppatori specifici per quel bug.
+</p>
+
+<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.
+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
+entro la data di rilascio concordata, in modo tale da poterlo rilasciare con
+tutte le keyword necessarie insieme al GLSA nello stesso istante in cui il
+rilascio dell'ebuild diventa pubblico.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Preparare bozze di GLSA con GLSAMaker</title>
+<section>
+<title>Regole Generali</title>
+<body>
+
+<p>
+Il GLSA dovrebbe utilizzare il nome del software colpito prestando attenzione a
+maiuscole/minuscole, non utilizzando, quindi il nome di pacchetto Gentoo. Per
+esempio, dovreste utilizzare "MySQl" e non "mysql". I nomi in minuscolo
+dovrebbero essere utilizzati solo se il software ha un nome tutto in minuscolo o
+se il software è identificato dal nome del suo comando (ad esempio
+"traceroute").
+</p>
+
+<p>
+Non copiare nessuna parte di una descrizione già esistente, ma utilizzarle come
+fonti d'informazione per il GLSA. Se viene copiato, per esempio, una descrizione
+di un software da un sito internet, si prega di utilizzare una citazione e le
+virgolette.
+</p>
+
+</body>
+</section>
+<section>
+<title>Titolo, Sinossi, Keyword</title>
+<body>
+
+<p>
+Il titolo deve essere corto (< 60 caratteri nella maggior parte dei casi) ed
+indicare il nome dell'applicazione (non la categoria). Dovrebbe consentire
+d'identificare chiaramente la vulnerabilità senza entrare nei dettagli. La
+versione dovrebbe essere omessa, tranne nei rari casi in cui sia permesso
+identificare un pacchetto più chiaramente. I pacchetti multipli colpiti
+dovrebbero essere separati da una virgola. Gli esempi includono:
+</p>
+
+<table>
+<tr>
+ <ti>MySQL: creazione insicura di un file temporaneo</ti>
+</tr>
+<tr>
+ <ti>Exim: verify=header_syntax buffer overflow</ti>
+</tr>
+<tr>
+ <ti>Apache 1.3: Heap overflow in mod_redirect</ti>
+</tr>
+<tr>
+ <ti>MPlayer, xine-lib: Vulnerabilities in RTSP stream handling</ti>
+</tr>
+</table>
+
+<p>
+La sinossi è una corta (< 160 caratteri) ma completa descrizione della
+vulnerabilità. Gli esempi includono:
+</p>
+
+<table>
+<tr>
+ <ti>
+ Due utilità MySQL creano file temporanei con percorsi fissi, consentendo
+ ad un attaccante di utilizzare un collegamento simbolico per ingannare MySQL
+ nel sovrascrivere dati importanti.
+ </ti>
+</tr>
+<tr>
+ <ti>
+ Sono stati rilevati vulnerabilità multiple, inclusi buffer overflow
+ eseguibili da remoto, nel codice comune tra Mplayer e la libreria xine
+ </ti>
+</tr>
+</table>
+
+<p>
+La categoria delle keyword GLSA è solitamente impostata a "Ebuild" e dovrebbe
+contenere il nome del principale software vulnerabile (per esempio "MySQL").
+Altri tipi di keyword includono "Portage" (per bug del portage) e
+"Infrastructure" (compromissioni dei servers).
+</p>
+
+</body>
+</section>
+<section>
+<title>Accesso, Severity</title>
+<body>
+
+<p>
+L'accesso dovrebbe essere "Locale" o "Remoto". Le vulnerabilità locali possono
+essere gestite solo da un utente locale del sistema in questione. Per esempio
+implica eseguire uno script per elevare i privilegi, oppure accedere ad una
+directory temporanea per far partire un attacco tramite collegamento simbolico.
+Le vulnerabilità remote sono quelle che possono essere eseguite da un attaccante
+con o senza un account sul sistema bersaglio. Le vulnerabilità remote possono
+essere sia attive (sfruttando un server in ascolto per inviare codice maligno) o
+passive (attirare un utente per collegare il software residente sul client ad un
+server "maligno" o ad aprire file con codice analogo).
+</p>
+
+<p>
+La severità è un'indicazione di quanto in profondità arrivi la vulnerabilità.
+Viene definita nella Vulnerability Treatment Policy, nella tabella "Evaluate the
+vulnerability type". Si noti che dipende solo dal massimo rischio, non al
+fattore comune della configurazione delle opzioni al rischio. Un buffer overflow
+che consenta l'esecuzione di codice arbitrario in un raro client software, solo
+quando si utilizza una specifica opzione di configurazione, teoricamente rimane
+una severità Alta". Un DoS in tutte le configurazioni di Apache teoricamente
+resta severità "Normale". In rari casi la severità può essere corretta, quando
+molti membri del team di sicurezza sono d'accordo, verso un livello più alto.
+Per esempio, una vulnerabilità che consentisse il deface di un sito internet in
+Apache ed in tutte le configurazioni dovrebbe probabilmente essere a severità
+"Alta" piuttosto che "Normale"
+</p>
+
+</body>
+</section>
+<section>
+<title>Pacchetti vulnerabili, inalterati</title>
+<body>
+
+<p>
+Questa sezione fornisce informazioni sulle versioni dei pacchetti che sono
+rimasti inalterati o vulnerabili alla vulnerabilità descritta nell'informativa
+corrente. Prestare attenzione particolare a quei numeri, perché rappresentano
+una delle poche zone dove ogni errore implica un'errata pubblicazione.
+</p>
+
+<p>
+Ci sono diversi campi che compongono il valore di una versione. Il campo
+contenente il nome del pacchetto deve elencare il nome del pacchetto e la
+categoria ("net-mail/exim"). Riguardo il campo "Architetture", inserire "*"
+quando la descrizione della versione si applica a tutte le architetture
+contrassegnate nell'ebuild. Utilizzare voci multiple per architetture differenti
+se la descrizione della versione è differente di architettura in architettura.
+Il campo "Auto" deve essere impostato a "true" se il pacchetto è aggiornabile
+via emerge. Per i campi versione possono esservi molteplici casistiche.
+</p>
+
+<impo>
+In questa sezione (e soltanto in questa sezione), le architetture dovrebbero
+essere scritte così come compaiono nelle keyword (cioè "x86", "amd64",
+"sparc"...), e non in maiuscolo.
+</impo>
+
+<p>
+Il caso più semplice si verifica quando la vulnerabilità è presente in tutte
+le vecchie versioni ed è corretta in tutte le versioni più recenti rispetto alla
+versione di una specifica correzione. In questo caso, usare ">= prima
+versione corretta" come inalterata e "<= ultima versione colpita" come
+vulnerabile. Controllare più volte che non esista un'ebuild fra l'ultima
+versione colpita e la prima versione corretta. Qualora ci si trovasse in dubbio,
+usare ">= prima versione corretta" come inalterata e "<= prima versione
+corretta" come vulnerabile.
+</p>
+
+<p>
+Un caso più complesso si verifica quando la vulnerabilità si presenta soltanto
+in alcune versioni recenti. Si propone l'esempio di un pacchetto dove la
+versione 1.2.8-r2 non è stata colpita, le versioni 1.2.9, 1.2.9-r1 e 1.2.9-r2
+sono state colpite e la versione 1.2.10 è stata corretta. In questo caso ci sono
+due possibilità.
+</p>
+
+<table>
+<tr>
+ <th>Inalterata</th>
+ <th>Vulnerabile</th>
+</tr>
+<tr>
+ <ti>>=1.2.10</ti>
+ <ti>==1.2.9 ==1.2.9-r1 ==1.2.9-r2</ti>
+</tr>
+<tr>
+ <ti><=1.2.8-r2 >=1.2.10</ti>
+ <ti><1.2.10</ti>
+</tr>
+</table>
+
+<p>
+Per concludere, quando il pacchetto non ha una versione corretta, omettere
+l'opzione "inalterato" (unaffected) per quel pacchetto ed impostare "Auto" a
+"no".
+</p>
+
+<impo>
+Quando le versioni delle correzioni sono complesse, controllare più volte che le
+versioni XML e TXT del GLSA elenchino correttamente le proprie versioni
+</impo>
+
+</body>
+</section>
+<section>
+<title>Background, Descrizione, Impatto</title>
+<body>
+
+<p>
+La sezione Background fornisce le informazioni sul pacchetto a rischio. Descrive
+brevemente cos'è e fornisce tutte le informazioni utili a comprendere la parte
+del pacchetto vulnerabile. La sezione Background dovrebbe essere più corta della
+sezione di descrizione o della sezione impatto (Impact). Tra gli esempi da
+seguire si include:
+</p>
+
+<table>
+<tr>
+ <ti>
+ Il K Desktop Environment (KDE) è un potente ambiente grafico desktop della
+ Free Software Foundation. KDE usa gli URI handlers per innescare vari
+ programmi quando vengono ricevute delle URL specifiche.
+ </ti>
+</tr>
+<tr>
+ <ti>
+ CVS (Concurrent Versions System) è un sistema open-source di controllo di
+ versione network-transparent. Contiene sia una client utility che un
+ server.
+ </ti>
+</tr>
+<tr>
+ <ti>
+ Metamail è un programma che decodifica la posta codificata MIME. Viene
+ quindi spesso automaticamente invocato quando una email viene letta o
+ ricevuta.
+ </ti>
+</tr>
+</table>
+
+<p>
+La sezione "descrizione" descrive più in dettaglio qual è la vulnerabilità senza
+dire cosa accade quando questa viene sfruttata. Dovrebbe essere comprensibile da
+persone senza grandissime basi di sicurezza. A volte non si trovano affatto le
+informazioni sulla vulnerabilità, in questi casi lasciare la descrizione
+breve. Tra i buoni esempi si include:
+</p>
+
+<table>
+<tr>
+ <ti>
+ Il Telnet URI handler in Opera non controlla l'esistenza di caratteri '- '
+ iniziali nell'hostname. Di conseguenza, un link maligno del tipo telnet://
+ potrebbe essere capace di passare opzioni al telnet stesso. Un esempio
+ sarebbe "telnet://-nMyFile". Se MyFile esiste nella home directory
+ dell'utente e l'utente che clicca sul link ha i permessi di scrittura su di
+ esso, i contenuti del file saranno sovrascritti con'output delle
+ informazioni del telnet trace. Se MyFile non esiste, il file verrà generato
+ nella home directory dell'utente.
+ </ti>
+</tr>
+<tr>
+ <ti>
+ L'utility di bug reporting di MySQL(mysqlbug) genera un file temporaneo per
+ loggarvi i bug reports. Un utente locale "maligno" con diritti di scrittura
+ su /tmp potrebbe generare un link simbolico dal nome mysqlbug-N puntante ad
+ un file protetto, come /etc/passwd, in modo tale che qualora mysqlbug
+ generasse l'ennesimo file di log, finirebbe con il sovrascrivere l'obiettivo
+ (in questo esempio, /etc/passwd). Una vulnerabilità simile esiste con la
+ mysql_multi utility, che genera una file temporaneo denominato
+ mysql_multi.log
+</ti>
+</tr>
+<tr>
+ <ti>
+ Vulnerabilità multiple sono state scovate e riparate nell'RTSP che gestisce
+ il codice in comune alle versioni recenti di questi due pacchetti. Queste
+ vulnerabilità includono parecchi buffer overflow sfruttabili da remoto.
+ </ti>
+</tr>
+</table>
+
+<p>
+La sezione "Impact" descrive l'effetto globale delle vulnerabilità descritte
+nella sezione "descrizione", una volta sfruttate. Dovrebbe focalizzarsi sul
+massimo rischio possibile. Buoni esempi sono:
+</p>
+
+<table>
+<tr>
+ <ti>
+ Un attaccante remoto, presentandosi come RTSP stream server, può eseguire
+ codice in modo arbitrario con i diritti dell'utente del software che sta
+ eseguendo lo stream (MPlayer o qualsiasi altro player che utilizzi
+ xine/xine-lib). Un altro attaccante può attirare un utente per usare un URL
+ "maligna" o una playlist per ottenere lo stesso identico risultato
+ </ti>
+</tr>
+<tr>
+ <ti>
+ Questo exploit ha due possibili effetti. In primo luogo, può generare nuovi
+ file nella home directory dell'utente. In secondo luogo, e molto più
+ pericoloso, può sovrascrivere i file esistenti per i quali l'utente ha i
+ permessi di scrittura. Un attaccante con una certa conoscenza della home
+ directory dell'utente potrebbe essere in grado di distruggere file
+ importanti salvati in quella directory.
+ </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Workaround, Soluzione</title>
+<body>
+
+<p>
+Il workaround descrive se esiste un qualsiasi maniera semplice (tranne
+l'aggiornamento alla versione correttiva) per evitare di essere vittime della
+vulnerabilità. I buoni esempi includono:
+</p>
+
+<table>
+<tr>
+ <ti>
+ Come workaround provvisorio, bypassando il supporto del Kerberos 4, potreste
+ spegnere il kadmin del Kerberos 4 facendo partire il kadmind con l'opzione
+ -- no-kerberos4.
+ </ti>
+</tr>
+<tr>
+ <ti>Ad oggi non esistono workaround conosciuti.</ti>
+</tr>
+</table>
+
+<p>
+La sezione "Risoluzione" spiega in termini umanamente comprensibili che cosa
+bisogna fare per essere completamente protetti dalla vulnerabilità. Questa
+sezione deve assomigliare a quanto segue:
+</p>
+
+<pre caption="Esempio di risoluzione">
+Tutti gli utenti di Heimdal dovrebbero effettuare l'aggiornamento all'ultima versione stabile:
+<code>
+# emerge sync
+# emerge --ask --oneshot --verbose ">=app-crypt/heimdal-0.6.2"
+</pre>
+
+<p>
+Qualora vi fossero più architetture, dovrebbe assomigliare a questa
+</p>
+
+<pre caption="Esempio per architetture multiple">
+Gli utenti di OpenOffice.org su SPARC dovrebbero:
+<code>
+# emerge sync
+# emerge --ask --oneshot --verbose ">=app-office/openoffice-1.1.0-r3"</code>
+</p>
+<p>
+
+Gli utenti di OpenOffice.org su PPC dovrebbero:
+</p>
+<code>
+# emerge sync
+# emerge --ask --oneshot --verbose ">=app-office/openoffice-1.0.3-r1"
+</pre>
+
+<p>
+Se il GLSA riguarda una libreria condivisa, includere il seguente paragrafo
+all'estremità della sezione "risoluzione" per avvisare circa la necessità di
+effettuare la ricompilazione degli eseguibili collegati.
+</p>
+
+<table>
+<tr>
+ <ti>
+ I pacchetti che dipendono da questa libreria possono avere bisogno di
+ essere ricompilati. Strumenti come revdep-rebuild possono aiutare
+ nell'identificare alcuni dei questi pacchetti.
+ </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Riferimenti</title>
+<body>
+
+<p>
+La sezione "Riferimenti" dovrebbe fornire i collegamenti alle informazioni di
+riferimento sulla vulnerabilità in questione. Quando un numero CVE
+(CVE-xxxx-xxx) è disponibile, dovrebbe essere fornito (con il numero CVE
+completo nel Titolo, "Title"). Si può anche collegare un advisory di uno
+sviluppatore originale e/o un'email di annuncio, quando disponibili. Evitare
+link ad advisory di altre distribuzioni o advisory non ufficiali provenienti da
+entità esterne.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Pubblicazione GLSA</title>
+<section>
+<title>Revisione tra colleghi</title>
+<body>
+
+<p>
+Quando la bozza iniziale è pronta, deve essere sottoposta alla revisione degli
+altri membri del team di sicurezza, effettuando una richiesta di revisione sul
+canale #gentoo-security. La versione finale (dopo che tutte le correzioni sono
+state applicate) deve essere approvata da due membri del team di sicurezza prima
+di essere committata e spedita.
+</p>
+
+<p>
+Nel rivedere la bozza di un GLSA, controllare con attenzione le seguenti cose:
+</p>
+
+<ul>
+ <li>
+ Versioni colpite/inalterate (Controllare nel Changelog che le versioni siano
+ corrette e assicurarsi che non vi siano versioni che non siano definite o
+ colpite o inalterate).
+ </li>
+ <li>Correttezza del titolo.</li>
+ <li>
+ Severity ed accesso (Non fare solo riferimento al rating del bug e se è
+ necessario un account locale o remoto per un accesso "local o remote").
+ </li>
+ <li>
+ Alla fine viene effettuato un sanity check: si verifica che sia veramente
+ una vulnerabilità e non un semplice bug (come le non-vulnerabilità di samba
+ e shadow)
+ </li>
+</ul>
+
+<p>
+Quando la bozza viene approvata, deve esserle assegnato un numero ufficiale
+GLSA. Ciò viene fatto chiamando la funzione "Move" in GLSAMaker per spostare la
+bozza dalla zona di sviluppo alla zona ufficiale.
+</p>
+
+</body>
+</section>
+<section>
+<title>GLSA XML commit</title>
+<body>
+
+<p>
+Bisogna effettuare il commit del GLSA XML nell'albero del CVS di Gentoo in modo
+che compaia automaticamente nella gestione del feed RDF, nella lista dei GLSA e
+negli aggiornamenti di portage. Aggiornare in primo luogo la propria directory
+GLSA nel tree del repository gentoo CVS:
+</p>
+
+<pre caption="Aggiornamento albero CVS">
+you@home you $ <i>cd gentoo_cvs</i>
+you@home gentoo_cvs $ <i>cvs update -dP gentoo/xml/htdocs/security</i>
+</pre>
+
+<p>
+A questo punto cliccare <c>Fetch</c> nel GLSA per scaricare la versione XML,
+e salvarla nella propria directory
+gentoo_cvs/gentoo/xml/htdocs/security/en/glsa/ . A questo punto effettuare il
+commit ed aggiungere il file XML:
+</p>
+
+<pre caption="Commit GLSA">
+you@home gentoo_cvs $ <i>cd gentoo/xml/htdocs/security/en/glsa</i>
+you@home glsa $ <i>cvs add glsa-YYYYMM-NN.xml</i>
+you@home glsa $ <i>cvs commit -m "GLSA YYYYMM-NN" glsa-YYYYMM-NN.xml</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Annuncio via E-mail</title>
+<body>
+
+<warn>
+Ogni volta che viene utilizzata una nuova installazione (software o macchina)
+per inviare un annuncio GLSA, assicurarsi che il proprio setup venga
+controllato, inviando un'email di test ad un altro membro del team di sicurezza.
+</warn>
+
+<p>
+Cliccare su Txt download per ottenere una versione di testo del GLSA.
+Controllare che la sezione colpite/inalterate (affected/unaffected) sembri a
+posto, quindi preparare una mail con le seguenti regole:
+</p>
+
+<ul>
+ <li>
+ <b>Da </b> e<b>Indirizzo di Ritorno</b> devono essere impostati a
+ tuonome@gentoo.org
+ </li>
+ <li>
+ <b>To</b> e<b>Cc</b> dovrebbero essere configurati secondo regolamento
+ </li>
+ <li>
+ <b>Oggetto</b> deve essere "[ GLSA XXXXYY-ZZ ] la propria vulnerabilità qui"
+ (copiare/incollare dal titolo nel file di testo)
+ </li>
+ <li>
+ Il corpo della mail dovrebbe corrispondere al contenuto del file di testo,
+ dall'intestazione "Gentoo Linux Security Advisory" alla fine del file
+ </li>
+ <li>
+ L'email deve essere firmata dalla chiave GPG per l'indirizzo
+ tuonome@gentoo.org
+ </li>
+</ul>
+
+<note>
+Si riceverà un'email di ritorno da gentoo-announce dicendo che è richiesta
+moderazione. Basta rispondere a questa mail e l'email di annuncio
+precedentemente menzionata arriverà a destinazione.
+</note>
+
+</body>
+</section>
+<section>
+<title>Chiusura dei bug</title>
+<body>
+
+<p>
+Controllare che la mail sia arrivata a gentoo-announce, poi è possibile chiudere
+i(l) bug relativo, regolando la condizione a <b>RESOLVED/FIXED</b>, con un
+commento indicante il numero di GLSA.
+</p>
+
+</body>
+</section>
+<section>
+<title>Pubblicazione Errata/Aggiornamenti</title>
+<body>
+
+<p>
+Un errata viene pubblicato quando viene commesso un errore, altrimenti si sta
+parlando di un aggiornamento. Quando la politica garantisce una ripubblicazione
+dovrebbero essere seguite queste linee guida:
+</p>
+
+<ul>
+ <li>
+ Il campo revisione dovrebbe essere correttamente impostato in XML. Ciò
+ significa che la revisione potrebbe avere bisogno di di essere corretta
+ manualmente nella directory data di GLSAMaker, se si effettuano cambiamenti
+ multipli usando GLSAMaker (es. <revised>September 10, 2004:
+ 02</revised>)
+ </li>
+ <li>
+ Se non sussiste vulnerabilità nessun pacchetto colpito dovrebbe essere
+ elencato nell'XML
+ </li>
+ <li>
+ Il titolo può cambiare (es. GLSA 200409-14 per Samba e GLSA 200411-01 per
+ ppp)
+ </li>
+ <li>
+ Non tutti gli Errata richiedono ripubblicazione. La politica spiega
+ dettagliatamente quando la ripubblicazione è necessaria.
+ </li>
+ <li>
+ Per la versione di testo GLSAmaker può aggiungere le informazioni relative
+ agli aggiornamenti ed alle errata. Si seguano manualmente le istruzioni
+ fornite da GLSAmaker.
+ </li>
+ <li>
+ La versione testuale deve contenere la sezione degli aggiornamenti o delle
+ errata (si veda l'esempio indicato sotto) e soltanto DOPO QUESTO solo
+ sezioni vengono cambiate (la versione XML non ha sezioni aggiuntive)
+ </li>
+</ul>
+
+<table>
+<tr>
+ <ti>
+ Questo advisory è stato descritto via ppp in maniera non corretta come
+ vulnerabile ad un DoS. Dopo ulteriori verifiche, sembra che un utente remoto
+ possa negare soltanto il servizio a sé stesso, quindi questo bug non induce
+ alcun problema di sicurezza. Le sezioni corrette compaiono qui sotto.
+ </ti>
+</tr>
+</table>
+
+<p>
+Ecco due esempi completi di errata email, si veda <uri
+link="http://archives.gentoo.org/gentoo-announce/msg_02598.xml">ERRATA: [
+GLSA 200409-14 ] Samba: Remote printing non-vulnerability</uri> (dove non sono
+presenti reali vulnerabilità) e <uri
+link="http://archives.gentoo.org/gentoo-announce/msg_02502.xml">ERRATA: [
+GLSA 200405-25 ] tla: Multiple vulnerabilities in included libneon</uri> (dove i
+problemi non sono risolti correttamente nella prima versione). Per un
+aggiornamento si veda <uri
+link="http://archives.gentoo.org/gentoo-announce/msg_02663.xml">UPDATE: [
+GLSA 200410-30 ] GPdf, KPDF, KOffice: Vulnerabilities in included xpdf</uri>
+(dove la correzione ha introdotto un'altra vulnerabilità ).
+</p>
+
+<p>
+Altrimenti dovrebbero essere seguite le linee guida standard GLSA.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Strumenti per i Coordinatori GLSA</title>
+<section>
+<title>Raccolta delle Informazioni</title>
+<body>
+
+<ul>
+ <li>
+ <uri link="http://dev.gentoo.org/~koon/packageview/">packageview</uri> è uno
+ strumento che aprirà packages.gentoo.org e Gentoo ViewCVS nel punto giusto
+ per una categoria e una nome pacchetto assegnati. Aiuta a determinare quali
+ keyword sono richieste per tracciare i cambiamenti di un pacchetto.
+ </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Guide GLSA per la pubblicazione</title>
+<body>
+
+<ul>
+ <li>
+ <uri link="http://dev.gentoo.org/~koon/glsacommit.txt">glsacommit</uri> è
+ una funzione bash che si occupa delle gestione del commit dei GLSA.
+ Caratterizzato dall'ssh-agent keyadding, glsa-check controlla più volte la
+ conformità ed ha delle funzioni "Sei sicuro?". Modificarlo per soddisfare le
+ proprie necessità e le posizioni delle directory.
+ </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
--
gentoo-commits@gentoo.org mailing list
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/security/it: coordinator_guide.xml
@ 2008-02-22 21:53 Davide Cendron (scen)
0 siblings, 0 replies; 7+ messages in thread
From: Davide Cendron (scen) @ 2008-02-22 21:53 UTC (permalink / raw
To: gentoo-commits
scen 08/02/22 21:53:36
Modified: coordinator_guide.xml
Log:
Version 0.8.5, revision 1.19 of EN CVS
Revision Changes Path
1.5 xml/htdocs/security/it/coordinator_guide.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.5&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.5&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?r1=1.4&r2=1.5
Index: coordinator_guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- coordinator_guide.xml 11 Nov 2007 22:02:22 -0000 1.4
+++ coordinator_guide.xml 22 Feb 2008 21:53:35 -0000 1.5
@@ -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.4 2007/11/11 22:02:22 scen Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v 1.5 2008/02/22 21:53:35 scen Exp $ -->
<guide link="/security/it/coordinator_guide.xml" lang="it">
<title>Guida per il Coordinatore dei GLSA</title>
@@ -11,6 +11,9 @@
<author title="Autore">
<mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail>
</author>
+<author title="Autore">
+ <mail link="vorlon@gentoo.org">Matthias Geerdsen</mail>
+</author>
<author title="Traduzione">
<mail link="dungeon01@gmail.com">Dungeon01</mail>
</author>
@@ -27,8 +30,8 @@
<!--Consultare http://creativecommons.org/licenses/by-sa/1.0 -->
<license/>
-<version>0.8.4</version>
-<date>2007-01-24</date>
+<version>0.8.5</version>
+<date>2007-02-13</date>
<chapter>
<title>Prerequisiti</title>
@@ -147,9 +150,9 @@
<p>
Tutti bug di sicurezza sono reperibili nella categoria <c>Gentoo Security</c> di
-Bugzilla. Se si individua un bug di sicurezza che ha un nome di categoria errato,
-si prega di correggerlo immediatamente. Vi sono differenti tipologie di bug di
-sicurezza, e ciascuno ha il proprio componente.
+Bugzilla. Se si individua un bug di sicurezza che ha un nome di categoria
+errato, si prega di correggerlo immediatamente. Vi sono differenti tipologie di
+bug di sicurezza, e ciascuno ha il proprio componente.
</p>
</body>
@@ -219,10 +222,10 @@
di quest'ultimo di mantenerlo segreto fino ad un pubblico rilascio. 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, come il manutentore del pacchetto od 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).
+esterni (il manutentore del pacchetto, il tester dell'architettura, Release
+Engineering) 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).
</p>
<p>
@@ -562,6 +565,12 @@
</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
@@ -1280,14 +1289,14 @@
<p>
Ecco due esempi completi di errata email, si veda <uri
-link="http://archives.gentoo.org/gentoo-announce/msg_02598.xml">ERRATA: [
+link="http://archives.gentoo.org/gentoo-announce/msg_02598.xml">ERRATA: [
GLSA 200409-14 ] Samba: Remote printing non-vulnerability</uri> (dove non sono
presenti reali vulnerabilità) e <uri
-link="http://archives.gentoo.org/gentoo-announce/msg_02502.xml">ERRATA: [
+link="http://archives.gentoo.org/gentoo-announce/msg_02502.xml">ERRATA: [
GLSA 200405-25 ] tla: Multiple vulnerabilities in included libneon</uri> (dove i
problemi non sono risolti correttamente nella prima versione). Per un
aggiornamento si veda <uri
-link="http://archives.gentoo.org/gentoo-announce/msg_02663.xml">UPDATE: [
+link="http://archives.gentoo.org/gentoo-announce/msg_02663.xml">UPDATE: [
GLSA 200410-30 ] GPdf, KPDF, KOffice: Vulnerabilities in included xpdf</uri>
(dove la correzione ha introdotto un'altra vulnerabilità ).
</p>
--
gentoo-commits@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/security/it: coordinator_guide.xml
@ 2008-03-16 17:20 Davide Cendron (scen)
0 siblings, 0 replies; 7+ messages in thread
From: Davide Cendron (scen) @ 2008-03-16 17:20 UTC (permalink / raw
To: gentoo-commits
scen 08/03/16 17:20:51
Modified: coordinator_guide.xml
Log:
Version 0.8.6, revision 1.21 of EN CVS
Revision Changes Path
1.6 xml/htdocs/security/it/coordinator_guide.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.6&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.6&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?r1=1.5&r2=1.6
Index: coordinator_guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- coordinator_guide.xml 22 Feb 2008 21:53:35 -0000 1.5
+++ coordinator_guide.xml 16 Mar 2008 17:20:50 -0000 1.6
@@ -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.5 2008/02/22 21:53:35 scen Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v 1.6 2008/03/16 17:20:50 scen Exp $ -->
<guide link="/security/it/coordinator_guide.xml" lang="it">
<title>Guida per il Coordinatore dei GLSA</title>
@@ -30,8 +30,8 @@
<!--Consultare http://creativecommons.org/licenses/by-sa/1.0 -->
<license/>
-<version>0.8.5</version>
-<date>2007-02-13</date>
+<version>0.8.6</version>
+<date>2008-03-13</date>
<chapter>
<title>Prerequisiti</title>
@@ -1317,10 +1317,10 @@
<ul>
<li>
- <uri link="http://dev.gentoo.org/~koon/packageview/">packageview</uri> è uno
- strumento che aprirà packages.gentoo.org e Gentoo ViewCVS nel punto giusto
- per una categoria e una nome pacchetto assegnati. Aiuta a determinare quali
- keyword sono richieste per tracciare i cambiamenti di un pacchetto.
+ <uri link="http://dev.gentoo.org/~vorlon/packageview/">packageview</uri> è
+ uno strumento che aprirà packages.gentoo.org e Gentoo ViewCVS nel punto
+ giusto per una categoria e una nome pacchetto assegnati. Aiuta a determinare
+ quali keyword sono richieste per tracciare i cambiamenti di un pacchetto.
</li>
</ul>
@@ -1332,7 +1332,7 @@
<ul>
<li>
- <uri link="http://dev.gentoo.org/~koon/glsacommit.txt">glsacommit</uri> è
+ <uri link="http://dev.gentoo.org/~falco/glsacommit.txt">glsacommit</uri> è
una funzione bash che si occupa delle gestione del commit dei GLSA.
Caratterizzato dall'ssh-agent keyadding, glsa-check controlla più volte la
conformità ed ha delle funzioni "Sei sicuro?". Modificarlo per soddisfare le
--
gentoo-commits@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/security/it: coordinator_guide.xml
@ 2009-05-28 21:45 Davide Cendron (scen)
0 siblings, 0 replies; 7+ messages in thread
From: Davide Cendron (scen) @ 2009-05-28 21:45 UTC (permalink / raw
To: gentoo-commits
scen 09/05/28 21:45:46
Modified: coordinator_guide.xml
Log:
Version 0.8.8, revision 1.23 of EN CVS
Revision Changes Path
1.7 xml/htdocs/security/it/coordinator_guide.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.7&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.7&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?r1=1.6&r2=1.7
Index: coordinator_guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- coordinator_guide.xml 16 Mar 2008 17:20:50 -0000 1.6
+++ coordinator_guide.xml 28 May 2009 21:45:46 -0000 1.7
@@ -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.6 2008/03/16 17:20:50 scen Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v 1.7 2009/05/28 21:45:46 scen Exp $ -->
<guide link="/security/it/coordinator_guide.xml" lang="it">
<title>Guida per il Coordinatore dei GLSA</title>
@@ -14,6 +14,9 @@
<author title="Autore">
<mail link="vorlon@gentoo.org">Matthias Geerdsen</mail>
</author>
+<author title="Autore">
+ <mail link="rbu@gentoo.org">Robert Buchholz</mail>
+</author>
<author title="Traduzione">
<mail link="dungeon01@gmail.com">Dungeon01</mail>
</author>
@@ -30,8 +33,8 @@
<!--Consultare http://creativecommons.org/licenses/by-sa/1.0 -->
<license/>
-<version>0.8.6</version>
-<date>2008-03-13</date>
+<version>0.8.8</version>
+<date>2009-05-09</date>
<chapter>
<title>Prerequisiti</title>
@@ -42,9 +45,9 @@
<p>
Deve essere definito un determinato numero di account prima di lavorare come
coordinatore di GLSA. Per generare un GLSA è necessario ottenere un account <uri
-link="https://dev.gentoo.org/glsamaker/">GLSAMaker</uri>. Per gestire bug di
+link="https://glsamaker.gentoo.org:4433/">GLSAMaker</uri>. Per gestire bug di
sicurezza bisogna avere un account su <uri
-link="http://bugs.gentoo.org">Bugzilla</uri>, aggiornato con privilegi di
+link="https://bugs.gentoo.org">Bugzilla</uri>, aggiornato con privilegi di
<c>editbugs</c>. Per poter inviare un GLSA bisogna avere un indirizzo del tipo
tuonome@gentoo.org (in questo caso per essere uno sviluppatore Gentoo). Questo
indirizzo email dovrà poi essere autorizzato ad inviare messaggi al
@@ -70,12 +73,12 @@
<p>
A questo punto bisogna creare una chiave GPG per il proprio account email
tuonome@gentoo.org. È possibile generare una chiave specifica o aggiungere
-l'indirizzo @gentoo.org ad una chiave già esistente. Successivamente si
-dovrà inviare il proprio key ID al team "devrel" (Relazioni tra Sviluppatori,
-ndt), controllando inoltre che il proprio nome e lo key ID appaiano nell'<uri
-link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">elenco
-degli sviluppatori</uri>. È molto importante che la chiave venga pubblicata
-almeno sul server delle chiavi <uri
+l'indirizzo @gentoo.org ad una chiave già esistente. Successivamente il proprio
+key ID dovrebbe <uri link="/proj/en/infrastructure/ldap.xml">impostato in
+LDAP</uri>, controllando inoltre che il proprio nome e lo key ID appaiano
+nell'<uri link="/proj/en/devrel/roll-call/userinfo.xml">elenco degli
+sviluppatori</uri>. È molto importante che la chiave venga pubblicata almeno sul
+server delle chiavi <uri
link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri>, tuttavia la si può
pubblicare anche su altri.
</p>
@@ -119,7 +122,7 @@
</tr>
<tr>
<ti>bugtraq@securityfocus.com</ti>
- <ti><uri>http://www.securityfocus.com/subscribe</uri></ti>
+ <ti><uri>http://www.securityfocus.com/archive</uri></ti>
</tr>
<tr>
<ti>full-disclosure@lists.grok.org.uk</ti>
@@ -214,18 +217,19 @@
</body>
</section>
<section>
-<title>Bug di tipo "Restricted"</title>
+<title>Bug di tipo limitato ("Restricted")</title>
<body>
<p>
A volte un bug viene comunicato al Team di Sicurezza di Gentoo sotto promessa
-di quest'ultimo di mantenerlo segreto fino ad un pubblico rilascio. 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) 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).
+di quest'ultimo di mantenerlo segreto fino ad un pubblico rilascio, tipicamente
+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)
+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).
</p>
<p>
@@ -246,8 +250,8 @@
informazioni che dovrebbero essere tenute segrete fino ad una data di emissione
coordinata precedentemente concordata. Nessun aspetto del bug (nome del
pacchetto colpito, descrizione, patch proposte e qualsiasi altra cosa) dovrebbe
-mai uscire allo scoperto. Le patch NON dovrebbero essere inserite nel CVS
-di portage.
+mai uscire allo scoperto. Le patch NON devono essere inserite nel CVS di
+portage.
</p>
<p>
@@ -295,7 +299,9 @@
</tr>
<tr>
<ti>coordinatore</ti>
- <ti>Il nickname del coordinatore assegnato al bug in questione</ti>
+ <ti>
+ Il nickname del coordinatore assegnato al bug in questione, opzionalmente
+ </ti>
<ti>koon</ti>
</tr>
</table>
@@ -622,7 +628,7 @@
<p>
I bug confidenziali dovrebbero seguire questo modello: "RATING [status]
-coordinatore / Data_di_Rilascio CLASSIFIED", dove:
+coordinatore / KEYWORD CRD", dove:
</p>
<table>
@@ -640,23 +646,29 @@
</tr>
<tr>
<ti>[status]</ti>
- <ti>Lo stato effettivo del bug, con informazioni aggiuntive(opzionali</ti>
+ <ti>Lo stato effettivo del bug, con informazioni aggiuntive (opzionali)</ti>
<ti>[ebuild+]</ti>
</tr>
<tr>
<ti>coordinator</ti>
- <ti>Il nickname del coordinatore assegnato al bug in questione</ti>
+ <ti>Il nickname del coordinatore assegnato al bug in questione, opzionale</ti>
<ti>koon</ti>
</tr>
<tr>
- <ti>Release_date</ti>
- <ti>La data convenuta per la rilevazione coordinata</ti>
- <ti>20050106</ti>
+ <ti>KEYWORD</ti>
+ <ti>
+ Il livello confidenziale del bug, può essere CLASSIFIED, CONFIDENTIAL,
+ SEMI-PUBLIC
+ </ti>
+ <ti>CLASSIFIED</ti>
</tr>
<tr>
- <ti>CLASSIFIED</ti>
- <ti>Il flag opzionale CLASSIFIED per bug classificati</ti>
- <ti>CLASSIFIED</ti>
+ <ti>CRD</ti>
+ <ti>
+ La data di rilascio coordinato per la rivelazione dei bug. Se non viene
+ fornito un'orario, prendere come riferimento 14.00 UTC
+ </ti>
+ <ti>2009-01-06 18:00 UTC</ti>
</tr>
</table>
@@ -674,7 +686,7 @@
<ti>preebuild</ti>
<ti>
Il mantenitore del pacchetto specifico è stato chiamato a preparare
- un'ebuild che non dovrebbe essere inserita nel tree del CVS
+ un'ebuild che non deve essere inserita nel tree del CVS, ma allegata al bug
</ti>
</tr>
<tr>
@@ -999,9 +1011,9 @@
</tr>
<tr>
<ti>
- Questo exploit ha due possibili effetti. In primo luogo, può generare nuovi
- file nella home directory dell'utente. In secondo luogo, e molto più
- pericoloso, può sovrascrivere i file esistenti per i quali l'utente ha i
+ Questa vulnerabilità ha due possibili effetti. In primo luogo, può generare
+ nuovi file nella home directory dell'utente. In secondo luogo, e molto più
+ pericolosao, può sovrascrivere i file esistenti per i quali l'utente ha i
permessi di scrittura. Un attaccante con una certa conoscenza della home
directory dell'utente potrebbe essere in grado di distruggere file
importanti salvati in quella directory.
@@ -1289,16 +1301,16 @@
<p>
Ecco due esempi completi di errata email, si veda <uri
-link="http://archives.gentoo.org/gentoo-announce/msg_02598.xml">ERRATA: [
-GLSA 200409-14 ] Samba: Remote printing non-vulnerability</uri> (dove non sono
-presenti reali vulnerabilità) e <uri
-link="http://archives.gentoo.org/gentoo-announce/msg_02502.xml">ERRATA: [
-GLSA 200405-25 ] tla: Multiple vulnerabilities in included libneon</uri> (dove i
-problemi non sono risolti correttamente nella prima versione). Per un
+link="http://archives.gentoo.org/gentoo-announce/msg_59c7b7e81a7acacb1cbde24ab708f07a.xml">
+ERRATA: [GLSA 200409-14 ] Samba: Remote printing non-vulnerability</uri> (dove
+non sono presenti reali vulnerabilità) e <uri
+link="http://archives.gentoo.org/gentoo-announce/msg_e75f5d493fea7c6f718a850abd59598a.xml">
+ERRATA: [GLSA 200801-09 ] X.Org X server and Xfont library: Multiple vulnerabilities</uri>
+(dove i problemi non sono risolti correttamente nella prima versione). Per un
aggiornamento si veda <uri
-link="http://archives.gentoo.org/gentoo-announce/msg_02663.xml">UPDATE: [
-GLSA 200410-30 ] GPdf, KPDF, KOffice: Vulnerabilities in included xpdf</uri>
-(dove la correzione ha introdotto un'altra vulnerabilità ).
+link="http://archives.gentoo.org/gentoo-announce/msg_0f18bca197c64b634db757a18d2ae492.xml">
+UPDATE: [GLSA 200410-30 ] GPdf, KPDF, KOffice: Vulnerabilities in included
+xpdf</uri> (dove la correzione ha introdotto un'altra vulnerabilità ).
</p>
<p>
@@ -1342,5 +1354,21 @@
</body>
</section>
+<section>
+<title>Security Subversion repository</title>
+<body>
+
+<ul>
+ <li>
+ Il <uri link="http://overlays.gentoo.org/proj/security/timeline">Repository
+ Subversion Sicurezza</uri> contiene diversi strumenti per valutare in modo
+ collaborativo se Gentoo è affetta da nuovi identificatori CVE, e strumenti
+ per determinare le keywords di destinazione. Molti strumenti interagiscono
+ direttamente con Bugzilla, rendendo non necessari i copia-incolla manuali.
+ </li>
+</ul>
+
+</body>
+</section>
</chapter>
</guide>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/security/it: coordinator_guide.xml
@ 2009-10-06 20:41 Davide Cendron (scen)
0 siblings, 0 replies; 7+ messages in thread
From: Davide Cendron (scen) @ 2009-10-06 20:41 UTC (permalink / raw
To: gentoo-commits
scen 09/10/06 20:41:55
Modified: coordinator_guide.xml
Log:
Revision 1.24 of EN CVS
Revision Changes Path
1.8 xml/htdocs/security/it/coordinator_guide.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.8&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.8&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?r1=1.7&r2=1.8
Index: coordinator_guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- coordinator_guide.xml 28 May 2009 21:45:46 -0000 1.7
+++ coordinator_guide.xml 6 Oct 2009 20:41:54 -0000 1.8
@@ -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.7 2009/05/28 21:45:46 scen Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v 1.8 2009/10/06 20:41:54 scen Exp $ -->
<guide link="/security/it/coordinator_guide.xml" lang="it">
<title>Guida per il Coordinatore dei GLSA</title>
@@ -558,8 +558,10 @@
<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. Gli alias per
-le varie architetture sono del tipo architettura@gentoo.org (x86@gentoo.org,
+loro di contrassegnare l'ebuild come "stable" o ~ 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/security/it: coordinator_guide.xml
@ 2009-11-08 17:01 Davide Cendron (scen)
0 siblings, 0 replies; 7+ messages in thread
From: Davide Cendron (scen) @ 2009-11-08 17:01 UTC (permalink / raw
To: gentoo-commits
scen 09/11/08 17:01:25
Modified: coordinator_guide.xml
Log:
Revision 1.25 of EN CVS
Revision Changes Path
1.9 xml/htdocs/security/it/coordinator_guide.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.9&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?rev=1.9&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/security/it/coordinator_guide.xml?r1=1.8&r2=1.9
Index: coordinator_guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- coordinator_guide.xml 6 Oct 2009 20:41:54 -0000 1.8
+++ coordinator_guide.xml 8 Nov 2009 17:01:24 -0000 1.9
@@ -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.8 2009/10/06 20:41:54 scen Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v 1.9 2009/11/08 17:01:24 scen Exp $ -->
<guide link="/security/it/coordinator_guide.xml" lang="it">
<title>Guida per il Coordinatore dei GLSA</title>
@@ -493,11 +493,12 @@
<p>
Se il manutentore non lo rivela, si arriva allo stato [ebuild+]. In casi di
-versione correttiva, testare se un semplice incremento di versione funziona
-(basta rinominare l'ebuild all'ultima versione e farne l'emerge). In casi di
-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 testarlo.
+una versione correttiva disponibile, testare se un semplice incremento di
+versione funziona (basta rinominare l'ebuild all'ultima versione 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
+testarlo.
</p>
<p>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/security/it: coordinator_guide.xml
@ 2012-11-07 12:12 Agostino Sarubbo (ago)
0 siblings, 0 replies; 7+ messages in thread
From: Agostino Sarubbo (ago) @ 2012-11-07 12:12 UTC (permalink / raw
To: gentoo-commits
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-11-07 12:13 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-11 22:02 [gentoo-commits] gentoo commit in xml/htdocs/security/it: coordinator_guide.xml Davide Cendron (scen)
-- strict thread matches above, loose matches on Subject: below --
2008-02-22 21:53 Davide Cendron (scen)
2008-03-16 17:20 Davide Cendron (scen)
2009-05-28 21:45 Davide Cendron (scen)
2009-10-06 20:41 Davide Cendron (scen)
2009-11-08 17:01 Davide Cendron (scen)
2012-11-07 12:12 Agostino Sarubbo (ago)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox