Attachment 57569 Details for Bug 81639 – xmllint checked, updated and fixed grammatical errors (except the word wranglers)

xmllint checked, updated and fixed grammatical errors (except the word wranglers)

coordinator_guide.xml (text/plain), 41.35 KB, created by dungeon01 on 2005-04-29 05:24:03 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: dungeon01

Created: 2005-04-29 05:24:03 UTC

Size: 41.35 KB

patch

obsolete

><?xml version='1.0' encoding="UTF-8"?>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
><guide link="/security/en/coordinator_guide.xml">
><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>
>
>
>
><license/>
>
><version>0.8.1</version>
><date>March 7, 2005</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>Sootoscrizioni 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 ebiulds 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 prortage, 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 Ã¨ ncessario 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(&lt; 60  caratteri nella maggior parte dei casi) ed indicare il nome dell'applicazione (non la categoria).  Dovrebbe consentire d'indentificare chiaramente la vulnerabilitiÃ  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 (&lt; 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 "&gt;= prima versione corretta" come inalterata e "&lt;= 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  "&gt;= prima versione corretta" come inalterata e "&lt;= 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>&gt;=1.2.10</ti>
><ti>==1.2.9 ==1.2.9-r1 ==1.2.9-r2</ti>
></tr>
><tr>
><ti>&lt;=1.2.8-r2 &gt;=1.2.10</ti>
><ti>&lt;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 "&gt;=app-crypt/heimdal-0.6.2"
># emerge "&lt;=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:
>&lt;code&gt;
># emerge sync
>
># emerge -pv "&lt;=app-office/openoffice-1.1.0-r3"
># emerge "&lt;=app-office/openoffice-1.1.0-r3"
>&lt;/code&gt;
>&lt;/p&gt;
>&lt;p&gt;
>
>Gli utenti di OpenOffice.org  su PPC dovrebbero:
>&lt;/p&gt;
>&lt;code&gt;
># emerge sync
>
># emerge -pv "&gt;=app-office/openoffice-1.0.3-r1"
># emerge "&gt;=app-office/openoffice-1.0.3-r1"&lt;/code&gt;
></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>
>Diovreste 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. &lt;revised&gt;September 10, 2004: 02&lt;/revised&gt;)</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 aggiornamento 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>
>  Ecoo 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>
>  (where there were no real vulnerability) 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://securityfocus.com/archive/1/380493/2004-11-01/2004-11-07/0">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>
>

Actions: View

Attachments on bug 81639: 51007 | 51008 | 51258 | 51269 | 51271 | 57569