public inbox for gentoo-docs-it@lists.gentoo.org
 help / color / mirror / Atom feed
From: Davide Cendron <scen@gentoo.org>
To: gentoo-docs-it@lists.gentoo.org
Subject: Re: [gentoo-docs-it] Preview "Guida coordinatore"
Date: Thu, 18 Oct 2007 21:36:13 +0200	[thread overview]
Message-ID: <200710182136.18529.scen@gentoo.org> (raw)
In-Reply-To: <200710160034.19536.scen@gentoo.org>


[-- Attachment #1.1: Type: text/plain, Size: 1288 bytes --]

Il Tuesday 16 October 2007 00:34:15 Davide Cendron ha scritto:
> Il Sunday 14 October 2007 10:36:50 Luigi 'Comio' Mantellini ha scritto:
> > Prima di postare su bugs.* ecco il documento.
>
> Ciao Luigi, grazie per il contributo.
>
> Siccome ci sono un pò di cose da sistemare, non penso di riuscire a finire
> la revisione prima di domani sera (porta pazienza :P ^_^ )
>
> Intanto, se vuoi, comincia pure (se non hai già coiminciato), con
> security/padawans.xml ;)
>
> Ciao e grazie,

X Luigi:

Ti invio la revisione del documento.

Aggiungo un paio di considerazioni:

- il documento era abbastanza "messo male", sia dal punto di vista della 
traduzione, sia dal punto di vista dello stile di codifica XML. Ti chiedo 
cortesemente di ricontrollare TUTTO il documento, quando ne prendi in mano 
uno, anche se devi solamente aggiornarne il contenuto.

- se hai la possibilità rileggilo, purtroppo qualche parte l'ho passata 
velocemente (sono cotto in questo periodo *_* ), per esempio ho lasciato 
alcuni termini non tradotti, se riesci a sostituirli con dei termini consoni 
in italiano ben venga ;)

Attendo il buggozzo 8)

Ciao e grazie,

-- 
Davide Cendron

Gentoo Documentation Project
Italian Lead Translator

http://www.gentoo.org/doc/it/

[-- Attachment #1.2: coordinator_guide.xml --]
[-- Type: text/xml, Size: 44134 bytes --]

<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header$ -->

<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 bisogna 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 inviare un GLSA bisogna avere un indirizzo
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 venga abilitata la possibilità
di fare "commit access" verso la GLSA directory nel CVS repository di
<c>gentoo</c>. Infine c'è bisogno di un nick IRC. Gli sviluppatori Gentoo sono
tenuti a mostrare il proprio nick nel canale #gentoo-security ogni volta che
sono 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
vostronome@gentoo.org. È possibile generare una chiave specifica o aggiungere
l'indirizzo gentoo.org ad una chiave già esistente. Inviare il proprio key ID
al team "devrel" (Relazioni tra Sviluppatori, ndt), controllare inoltre che il
proprio nome e key ID appaiano nell'<uri
link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">elenco
degli sviluppatori</uri>. E' 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 facendo 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 verranno 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 nel prodotto <c>Gentoo Security</c> di
Bugzilla . Se si individua un bug di sicurezza che ha un nome prodotto 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 risultano nei GLSA. I bug 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 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 essere come impostazione predefinita il più sicuri
possibile. I bug che toccano la configurazione predefinita vengono inseriti
quando tale configurazione, fornita con il pacchetto, può essere migliorata 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, questi 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 (mantenitori del pacchetto, 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". I primi (e i più segreti) sono
i bug <c>CLASSIFIED</c>. 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>. 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 mantenitore 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 inerente al 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 mantenitore 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 alla 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] , determinare di quali chiavi l'ebuild fornito necessita
prima che il glsa venga pubblicato. Ciò può essere ingannevole. Considerare ogni
versione attualmente presente in portage in modo che l'ebuild abbia <e>le stesse
o più keyword "stable"</e> di qualsiasi ogni 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 mantenitore 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 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 pacchetto 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 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 (&lt; 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 (&lt; 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 "&gt;= prima
versione corretta" come inalterata e "&lt;= 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 "&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. 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>&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, 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:
&lt;code&gt;
# emerge sync
# emerge --ask --oneshot --verbose "&gt;=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:
&lt;code&gt;
# emerge sync
# emerge --ask --oneshot --verbose "&gt;=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 --ask --oneshot --verbose "&gt;=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. &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 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>

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

      reply	other threads:[~2007-10-18 21:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-14  8:36 [gentoo-docs-it] Preview "Guida coordinatore" Luigi 'Comio' Mantellini
2007-10-15 22:34 ` Davide Cendron
2007-10-18 19:36   ` Davide Cendron [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200710182136.18529.scen@gentoo.org \
    --to=scen@gentoo.org \
    --cc=gentoo-docs-it@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox