Guida per il Coordinatore dei GLSA

1.  Prerequisiti

Account

Deve essere definito un determinato numero di account prima di lavorare come coordinatore di GLSA. Per generare un GLSA è necessario ottenere un account GLSAMaker. Per gestire bug di sicurezza bisogna avere un account su Bugzilla, aggiornato con privilegi di editbugs. 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 Gentoo. 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.

La chiave GPG

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 il proprio key ID dovrebbe impostato in LDAP, controllando inoltre che il proprio nome e lo key ID appaiano nell'elenco degli sviluppatori. È molto importante che la chiave venga pubblicata almeno sul server delle chiavi subkeys.pgp.net, tuttavia la si può pubblicare anche su altri.

Ambiente

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 Gentoo verso una directory data. (per esempio ~/gentoo_cvs):

you@home you $ mkdir gentoo_cvs
you@home you $ cd gentoo_cvs
you@home gentoo_cvs $ export CVS_RSH="ssh"
you@home gentoo_cvs $ export CVSROOT="yourname@cvs.gentoo.org:/var/cvsroot"
you@home gentoo_cvs $ cvs checkout gentoo/xml/htdocs/security

Sottoscrizioni a Mailing-list

Per poter inviare messaggi verso le liste dove saranno pubblicate le GLSA, bisogna iscrivere il proprio account tuonome@gentoo.org ad esse:

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.

2.  Tipi di bug di Sicurezza e componenti di Bugzilla

Tutti bug di sicurezza sono reperibili nella categoria Gentoo Security 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.

Vulnerabilità

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 Vulnerabilità (vulnerability).

Kernel

Le vulnerabilità sono trattate utilizzando una procedura a parte. Per distinguerle facilmente dagli altri bug, esse vengono archiviate sotto la categoria Kernel. I bug relativi al Kernel non risultano nei GLSA ma hanno il proprio meccanismo di pubblicazione (Gentoo KISS).

Configurazione Predefinita

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 Configurazione Predefinita non generano alcun GLSA.

Auditing

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 Auditing. Quando l'individuazione del bug è stata verificata, questo viene commutato a Vulnerabilità.

Bug di tipo limitato ("Restricted")

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, 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).

Vi sono tre differenti tipi di bug "restricted" (con limitazioni. ndt). I primi (e i più segreti) sono i bug CLASSIFIED (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 CLASSIFIED, 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 CLASSIFIED non dovrebbero mai essere aperti (resi cioè "UNRESTRICTED").

Il secondo tipo di bug è CONFIDENTIAL. 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 devono essere inserite nel CVS di portage.

Il terzo (e meno segreto) tipo di bug "Restricted" è dato dai bug SEMI-PUBLIC (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).

3.  Gestione pubblica della vulnerabilità del bug

Regole della "Status Whiteboard"

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:

Sono considerati validi i seguenti tipi di status:

Sono ammesse le seguenti informazioni aggiuntive:

Esempi:

Determinare lo stato di partenza del bug

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].

Stato dei bug in [upstream]

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].

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 enhancement.

Bug in stato [ebuild]

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]

Se il manutentore non lo rivela, si arriva allo stato [ebuild+]. In casi di 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.

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 enhancement.

Bug in stato [stable]

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 le stesse o più keyword "stable" di qualsiasi altro pacchetto presente nel portage. Ecco un esempio:

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 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 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].

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],

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.

Bug in stato [glsa]

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.

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.

4.  Gestione delle vulnerabilità dei bug "confidential"

Regole del pannello di stato (Status Whiteboard)

I bug confidenziali dovrebbero seguire questo modello: "RATING [status] coordinatore / KEYWORD CRD", dove:

I seguenti stati supplementari sono accettati per i bug confidenziali:

Maneggiare bug confidenziali

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.

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.

5.  Preparare bozze di GLSA con GLSAMaker

Regole Generali

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").

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.

Titolo, Sinossi, Keyword

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:

La sinossi è una corta (< 160 caratteri) ma completa descrizione della vulnerabilità. Gli esempi includono:

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).

Accesso, Severity

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).

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"

Pacchetti vulnerabili, inalterati

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.

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.

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.

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à.

Per concludere, quando il pacchetto non ha una versione corretta, omettere l'opzione "inalterato" (unaffected) per quel pacchetto ed impostare "Auto" a "no".

Background, Descrizione, Impatto

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:

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:

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:

Workaround, Soluzione

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:

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:

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"

Qualora vi fossero più architetture, dovrebbe assomigliare a questa

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"

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.

Riferimenti

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.

6.  Pubblicazione GLSA

Revisione tra colleghi

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.

Nel rivedere la bozza di un GLSA, controllare con attenzione le seguenti cose:

• 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).
• Correttezza del titolo.
• 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").
• 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)

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.

GLSA XML commit

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:

you@home you $ cd gentoo_cvs
you@home gentoo_cvs $ cvs update -dP gentoo/xml/htdocs/security

A questo punto cliccare Fetch 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:

you@home gentoo_cvs $ cd gentoo/xml/htdocs/security/en/glsa
you@home glsa $ cvs add glsa-YYYYMM-NN.xml
you@home glsa $ cvs commit -m "GLSA YYYYMM-NN" glsa-YYYYMM-NN.xml

Annuncio via E-mail

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:

• Da eIndirizzo di Ritorno devono essere impostati a tuonome@gentoo.org
• To eCc dovrebbero essere configurati secondo regolamento
• Oggetto deve essere "[ GLSA XXXXYY-ZZ ] la propria vulnerabilità qui" (copiare/incollare dal titolo nel file di testo)
• Il corpo della mail dovrebbe corrispondere al contenuto del file di testo, dall'intestazione "Gentoo Linux Security Advisory" alla fine del file
• L'email deve essere firmata dalla chiave GPG per l'indirizzo tuonome@gentoo.org

Chiusura dei bug

Controllare che la mail sia arrivata a gentoo-announce, poi è possibile chiudere i(l) bug relativo, regolando la condizione a RESOLVED/FIXED, con un commento indicante il numero di GLSA.

Pubblicazione Errata/Aggiornamenti

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:

• 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>)
• Se non sussiste vulnerabilità nessun pacchetto colpito dovrebbe essere elencato nell'XML
• Il titolo può cambiare (es. GLSA 200409-14 per Samba e GLSA 200411-01 per ppp)
• Non tutti gli Errata richiedono ripubblicazione. La politica spiega dettagliatamente quando la ripubblicazione è necessaria.
• Per la versione di testo GLSAmaker può aggiungere le informazioni relative agli aggiornamenti ed alle errata. Si seguano manualmente le istruzioni fornite da GLSAmaker.
• 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)

Ecco due esempi completi di errata email, si veda ERRATA: [GLSA 200409-14 ] Samba: Remote printing non-vulnerability (dove non sono presenti reali vulnerabilità) e ERRATA: [GLSA 200801-09 ] X.Org X server and Xfont library: Multiple vulnerabilities (dove i problemi non sono risolti correttamente nella prima versione). Per un aggiornamento si veda UPDATE: [GLSA 200410-30 ] GPdf, KPDF, KOffice: Vulnerabilities in included xpdf (dove la correzione ha introdotto un'altra vulnerabilità ).

Altrimenti dovrebbero essere seguite le linee guida standard GLSA.

7.  Strumenti per i Coordinatori GLSA

Raccolta delle Informazioni

• packageview è 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.

Guide GLSA per la pubblicazione

• glsacommit è 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.

Security Subversion repository

• Il Repository Subversion Sicurezza 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.

I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.