From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org)
by nuthatch.gentoo.org with esmtp (Exim 4.62)
(envelope-from <gentoo-docs-it+bounces-1686-garchives=archives.gentoo.org@gentoo.org>)
id 1HvzJE-0003bP-DQ
for garchives@archives.gentoo.org; Wed, 06 Jun 2007 17:28:37 +0000
Received: from robin.gentoo.org (localhost [127.0.0.1])
by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l56HS7hM027252;
Wed, 6 Jun 2007 17:28:07 GMT
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233])
by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l56HS35B027145
for <gentoo-docs-it@lists.gentoo.org>; Wed, 6 Jun 2007 17:28:04 GMT
Received: by wx-out-0506.google.com with SMTP id h27so330882wxd
for <gentoo-docs-it@lists.gentoo.org>; Wed, 06 Jun 2007 10:28:03 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
d=gmail.com; s=beta;
h=domainkey-signature:received:received:subject:from:to:content-type:date:message-id:mime-version:x-mailer;
b=ZXjD8a8RTjpwh8hGbwYtjTrchUkzJ3fpIllBrk6NrtZ2nElTUsb5G1VjvlIYmMcLCuahHQE5LBa7/yH6FQ1K8TEY/xLJesSmlc3LyRnFXfth9NRIMTI2P81qOOBvfaCIDF2DH7c3tAZ/3R/DsXXJzil6mfATkXFT2iadD2MFL7U=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=beta;
h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer;
b=BuQN75zjIZvHjPWMhKH96SKlnLcululvt4gRw0ayE7x6V6QywhySewRMWOzUH+T8Wc3UAwheSYLX78yKb6JLJg5EQf4fPOPx33/ff5wH8jNQXBCvtEi6MXElhkwZdgUEEilGYnlBFHjidtLNCAhNPvTljht/ysRxrGSL8DgjcaY=
Received: by 10.90.99.20 with SMTP id w20mr803905agb.1181150882490;
Wed, 06 Jun 2007 10:28:02 -0700 (PDT)
Received: from ?192.168.1.2? ( [151.37.48.139])
by mx.google.com with ESMTP id d24sm3012516nfh.2007.06.06.10.27.57;
Wed, 06 Jun 2007 10:27:59 -0700 (PDT)
Subject: [gentoo-docs-it] glsa coordinator_guide.xml
From: "Luigi 'Comio' Mantellini" <luigi.mantellini@gmail.com>
To: Traduttori Italiano Gentoo ML <gentoo-docs-it@lists.gentoo.org>
Content-Type: multipart/mixed; boundary="=-8nd3SbOYQ7HC/lflRjXn"
Date: Wed, 06 Jun 2007 13:51:51 +0200
Message-Id: <1181130711.11101.12.camel@cassini.comioland>
Precedence: bulk
List-Post: <mailto:gentoo-docs-it@lists.gentoo.org>
List-Help: <mailto:gentoo-docs-it+help@gentoo.org>
List-Unsubscribe: <mailto:gentoo-docs-it+unsubscribe@gentoo.org>
List-Subscribe: <mailto:gentoo-docs-it+subscribe@gentoo.org>
List-Id: Gentoo Linux mail <gentoo-docs-it.gentoo.org>
X-BeenThere: gentoo-docs-it@gentoo.org
Reply-to: gentoo-docs-it@lists.gentoo.org
Mime-Version: 1.0
X-Mailer: Evolution 2.10.1
X-Archives-Salt: 1df89a31-5698-4cd6-a592-71c40bb90cde
X-Archives-Hash: 1aa1fc247fe4583b4578d2e6f6403c44
--=-8nd3SbOYQ7HC/lflRjXn
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id l56HS7hR027252
Ho fatto l'aggiornamento del documento in oggetto (erano giusto due cose).
Il documento comunque necessita di una profonda revisione per correggere =
stile e formattazione. Dato che questo processo sar=C3=A0 un po' pi=C3=B9=
lungo (il tempo che ho non =C3=A8 tantissimo), procederei nel seguente m=
odo:
- Bug report di QUESTA versione per allineare comunque il cvs italiano;
- Revisione di sostanza per correggere il documento ed adattarlo nello s=
tile e nella forma;
- Secondo bug report con la versione REVISIONATA appena possibile.
Ovviamente, se siete d'accordo.
ciao
luigi
--=20
Luigi 'Comio' Mantellini
The three laws of users:
1. A user may not injure a sysadmin, or through inaction,
allow a sysadmin to come to harm.
2. A user must obey the orders given it by sysadmins except
where such orders would conflict with the First Law.
3. A user must protect its own existence as long as such
protection does not conflict with the First or Second Law.
--=-8nd3SbOYQ7HC/lflRjXn
Content-Disposition: attachment; filename=coordinator_guide.xml
Content-Type: application/xml; name=coordinator_guide.xml
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id l56HS7hR027252
<?xml version=3D'1.0' encoding=3D"UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link=3D"/security/it/coordinator_guide.xml" lang=3D"it">
<title>Guida per il Coordinatore dei GLSA </title>
<author title=3D"Autore">
<mail link=3D"koon@gentoo.org">Thierry Carrez</mail>
</author>
<author title=3D"Autore">
<mail link=3D"jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail>
</author>
<author title=3D"Traduzione">
<mail link=3D"dungeon01@gmail.com">Dungeon01</mail>
</author>
<abstract>
Questo documento contiene le procedure, i suggerimenti e soluzioni utili =
per il
coordinatore dei GLSA
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license =
-->
<!-- See 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>Accounts</title>
<body>
<p>
Prima di poter lavorare come coordinatore GLSA =C3=A8 necessario definire=
un certo
numero di accounts. Per generare un GLSA dovete ottenere un account
<uri link=3D"https://dev.gentoo.org/glsamaker/">GLSAMaker</uri>. Per gest=
ire bugs
di sicurezza dovete avere un account su <uri link=3D"http://bugs.gentoo.o=
rg">
Bugzilla</uri>, aggiornato con privilegi di <c>editbugs</c>. Per inviare =
un GLSA
dovete avere un indirizzo vostronome@gentoo.org (in questo caso per esser=
e uno
sviluppatore Gentoo). Questo indirizzo email dovr=C3=A0 poi essere autor=
izzato ad
inviare messaggi al mailing-group gentoo-announce. Per rendere definitiv=
i degli
XML di un GLSA =C3=A8 necessario che al vostro developer account venga ab=
ilitata la
possibilt=C3=A0 di fare "commit access" verso la directory GLSA nel CVS r=
epository di
<c>gentoo</c>. Infine avete bisogno di un nick IRC. Sarete tenuti a mostr=
are 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 render=
e pi=C3=B9
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=C3=A0 esistente. Il key ID dovreb=
be essere
inviato a devrelm e dovreste controllare che il vostro nome ed il vostro =
key ID
appaiano nella
<uri link=3D"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=3D"http://subkeys.pgp.net:11371">subkeys.pgp.net<=
/uri> .
Pu=C3=B2 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 ta=
le da
poter committare i vostri GLSA. Ci=C3=B2 viene reso possibile facendo il=
checkout di
una parte del CVS repository di <c>gentoo</c> verso una directory data.=20
(per esempio ~/gentoo_cvs):
</p>
<pre caption=3D"Impostazioni 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=3D"ssh"</i>
you@home gentoo_cvs $ <i>export CVSROOT=3D"yourname@cvs.gentoo.org:/var/c=
vsroot"</i>
you@home gentoo_cvs $ <i>cvs checkout gentoo/xml/htdocs/security</i>
</pre>
</body>
</section>
<section>
<title>Sottoscrizioni a Mailing-list </title>
<body>
<p>
Per poter postare verso le liste dove pubblicheremo i nostri GLSA, dovete
iscrivere il vostro account vostronome@gentoo.org ad esse:
</p>
<table>
<tr>
<th>Lista</th>
<th>Pagina d'iscrizione</th>
</tr>
<tr>
<ti>bugtraq@securityfocus.com</ti>
<ti><uri>http://www.securityfocus.com/subscribe</uri></ti>
</tr>
<tr>
<ti>full-disclosure@lists.grok.org.uk</ti>
<ti><uri>https://lists.grok.org.uk/mailman/listinfo/full-disclosure<=
/uri></ti> =20
</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-announc=
e,
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 Securit=
y</c>.
Se trovate un bug di sicurezza che ha un nome prodotto errato, per favore
correggetelo immediatamente. Vi sono differenti tipologie di bugs di sicu=
rezza,
e ciascuno ha il proprio componente.
</p>
</body>
</section>
<section>
<title>Vulnerabilit=C3=A0 </title>
<body>
<p>
Le vulnerabilit=C3=A0 sono bugs di sicurezza relativi all'upstream di un =
software o
bugs introdotti nell'impacchettamento delle ebuilds di Gentoo. Questi bug=
s
risultano nei GLSA. I bugs relativi al kernel hanno la loro propria categ=
oria e
non dovrebbero essere archiviati come <c>Vulnerabilit=C3=A0</c>.
</p>
</body>
</section>
<section>
<title>Kernel</title>
<body>
<p>
Le vulnerabilit=C3=A0 sono trattate utilizzando una procedura a parte. Pe=
r
distinguerle facilmente dagli altri bugs, esse vengono archiviate sotto l=
a
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 base</title>
<body>
<p>
I pacchetti Gentoo dovrebbero essere di default i pi=C3=B9 sicuri possibi=
le. I bugs
che toccano la default configuration vengono inseriti quando la configura=
zione
di default spedita con il pacchetto pu=C3=B2 essere migliorata in termini=
di
sicurezza. I Bugs relativi alla <c>Configurazione di base</c> non generan=
o
alcun GLSA
</p>
</body>
</section>
<section>
<title>Auditing</title>
<body>
<p>
Le Vulnerabilit=C3=A0 di Gentoo che vengono rilevate dovrebbero essere c=
ontrollate
pi=C3=B9 volte prima di uscire all'aperto (verso le liste di upstream o l=
e 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 =C3=A8 stata verificata,=
questo
viene commutato a <c>Vulnerabilit=C3=A0</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 mant=
enerlo
segreto fino ad un pubblico rilascio. I bugs limitati hanno la checkbox "=
Gentoo
Security" selezionata, e quindi possono essere raggiunti solo da membri d=
el
Gentoo Security Team. Gli attori esterni (maintainer del pacchetto, teste=
rs
dell'architettura) possono essere aggiunti in base nominale, gli alias no=
n
dovrebbero mai essere utilizzati (questo perch=C3=A8 gli alias sono tropp=
o larghi e
non permettono commenti ai bugs).
</p>
<p>
Vi sono tre differenti tipi di bugs "restricted". I primi (e i pi=C3=B9 s=
egreti) sono
i bugs <c>CLASSIFIED</c> (classificato). Un bug =C3=A8 definito CLASSIFIE=
D quando
contiene informazioni che non dovrebbero mai venir rilasciate. Questo inc=
lude
citazioni di email personali inviate a ristrette mailing-lists o patch
intermedie non rese pubbliche. I bugs classificati vengono identificati d=
alla
keyword <c>CLASSIFIED</c>, nella loro Status Whiteboard. Una volta CLASSI=
FIED,
un bug non pu=C3=B2 tornare allo stato non classificato se almeno due res=
ponsabili
della sicurezza siano d'accordo nel declassare il suddetto bug. I bugs
<c>CLASSIFIED</c> non dovrebbero mai essere aperti (resi cio=C3=A8 "UNRES=
TRICTED").
</p>
<p>
Il secondo tipo di bugs =C3=A8 <c>CONFIDENTIAL</c>. questi sono bugs cont=
enti
informazioni che dovrebbero essere tenute segrete fino ad una data di emi=
ssione
coordinata precedentemente concordata. Nessun aspetto del bug (nome del
pacchetto colpito, descrizione, patch proposte e qualsiasi altra cosa) do=
vrebbe
mai uscire allo scoperto. Le patch NON dovrebbero essere committate nel p=
ortage
CVS.
</p>
<p>
Il terzo (e meno segreto) tipo di bugs "Restricted" =C3=A8 dato dai bugs
<c>SEMI-PUBLIC</c>.
I bugs semipubblici dovrebbero restare segreti, ma le patch potrebbero es=
sere
committate al portage. Questo accade di solito quando la vulnerabilit=C3=A0=
non =C3=A8
sconosciuta dalla maggioranza del pubblico ma =C3=A8 accessibile da chiun=
que (per
esempio una patch in upstream sul CVS).
</p>
</body>
</section>
</chapter>
<chapter>
<title>Gestione pubblica della vulnerabilit=C3=A0 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=C3=A0 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 versio=
ne 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 sicur=
ezza
</ti>
</tr>
<tr>
<ti>stable</ti>
<ti>In attesa che le architetture contrassegnino il package con le keywor=
d
appropriate</ti>
</tr>
<tr>
<ti>stable+</ti>
<ti>Alcuni staff di architettura stanno mettendo troppo tempo per contras=
segnare
il package in manera appropriata</ti>
</tr>
<tr>
<ti>glsa?</ti>
<ti>La sicurezza deve decidere se =C3=A8 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 =C3=A8 in ritardo, ogni coordinatore di GLSA pu=C3=B2 corregg=
erlo 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 =C3=A8 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</t=
i>
<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 =C3=A8 stato pubblicato come soluzione temp=
oranea</ti>
<ti>upstream+, ebuild+</ti>
</tr>
<tr>
<ti>blocked</ti>
<ti>Quando il bug =C3=A8 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 correzione non =C3=A8 disponibile dallo sviluppatore upstream e=
/o non non =C3=A8
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 =C3=A8 in stato [inhouse]. Se =C3=A8 disponib=
ile una
correzione, il bug si trova nello stato [ebuild]. Se la correzione =C3=A8=
stata
inserita nel portage, il bug assume lo stato [stable]. Quando una correzi=
one =C3=A8
presente nel portage con tutte le chiavi richieste correttamente configur=
ate, 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 versio=
ne
della correzione o di una patch decente. Questo stato richiede controlli
regolari dell'upstream per informazioni: mailing lists di sviluppo e annu=
nci,
siti internet, bug database, CVS ove possibile, sono tutte fonti importan=
ti
d'informazioni. Patch non ufficiali devono essere considerate soltanto se=
lo
sviluppatore upstream non reagisce alla vulnerabilit=C3=A0, e devono esse=
re
controllate pi=C3=B9 volte per assicurarsi che non siano maligne. Quando =
viene
annunciata una nuova versione di una correzione, o una nuova patch viene
rilasciata, il bug entra nello stato [ebuild].
</p>
<p>
Se dall'upstream non v'=C3=A8 reazione n=C3=A9 patch alcuna, entriamo nel=
lo stato
[upstream+]. L'unica opzione consiste nell'applicare una security-mask al
pachetto vulnerabile e pubblicare un glsa temporaneo se necessario. Si ve=
da la
policy corrente per ulteriori dettagli inerenti alla procedura d'approvaz=
ione
del security-masking. Il panello di stato dovrebbe quindi essere flaggato=
con le
keyworkd maked e/o tempglsa e la bug severity impostata ad <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 correzione. 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 version=
e.
Dovreste mettere in cc: il gruppo e/o il maintainer responsabile del pacc=
hetto
inerente al bug e chiedere che venga fornita una ebuild per la versione d=
ella
correzione corrente. Dovreste controllare periodicamente che una ebuild n=
on 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 d=
i
versione di correzione, 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 d=
ovreste
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 =C3=A8 facile e/o si rileva un problema con l=
a ebuild in
questione, l'unica opzione consiste nell'applicare una security-mask al p=
achetto
non mantenuto e pubblicare un glsa temporaneo se necessario. Si veda la p=
olicy
corrente per ulteriori dettagli inerenti alla procedura d'approvazione de=
l
security-masking. Il panello di stato dovrebbe quindi essere flaggato con=
le
keyworkd maked 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], dovete determinare di quali chiavi l'ebuild fornita
necessita prima che il glsa venga pubblicato. Ci=C3=B2 pu=C3=B2 essere in=
gannevole. Dovete
considerare ogni versione attualmente presente nel portage in modo che l'=
ebuild
abbia <e>le stesse o pi=C3=B9 parole "stable"</e> di qualsiasi ogni altro=
package
presente nel portage. Qui v'=C3=A8 un esempio:
</p>
<table>
<tr>
<th>Versioni</th>
<th>Keyword</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 correzione deve avere:</ti>
<th>x86 ppc ~ia64</th>
</tr>
</table>
<note>
Potete usare <uri>http://packages.gentoo.org</uri> per aiutarvi nel deter=
minare
le keyword necessarie. Qualora i pacchetti interessati fossero stati rimo=
ssi
troppo presto dal maintainer del package stesso, dovreste usare l'accesso
<uri link=3D"http://www.gentoo.org/cgi-bin/viewcvs.cgi/">CVS</uri> per ce=
rcare
nell'archivio delle vecchie keyword.
</note>
<p>
Una volta determinate (ed inserite come riferimento nel bug) le keyword
necessarie, dovreste mettere in Cc: i team di sviluppo delle varie archit=
etture
chiedendo loro di contrassegnare l'ebuild come "stable" o ~ di conseguenz=
a. 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 keywo=
rd
nell'ebuild, dato che talvota queste vengono modificate senza lasciare n=
essun
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=
stable
un pacchetto per problemi non ancora risolti, il bug assume lo stato di
[stable+]. Dobbiamo rintracciare i maintainers delle varie architetture a=
ffinch=C3=A9
contrassegnino come stable il pacchetto, e diano supporto nel testing del=
lo
stesso. Dovreste anche convincere gli sviluppatori per le varie architett=
ure che
se scoprono un bug in un'ebuild che era gi=C3=A0 presente nelle precedent=
i versioni
"stable", l'ebuild dovrebbe essere contrassegnata come "stable" anche se =
non =C3=A8
attualmente stabile, come specificato nella policy. Se non possono essere
rintracciate le keyword, l'unica opzione rimanente =C3=A8 quella di appli=
care una
security-mask al package: non esiste alcuna versione accettabile non affe=
tta dal
bug, quindi =C3=A8 come se nessuna correzione accettabile sia stata forni=
ta in
upstream.
</p>
</body>
</section>
<section>
<title>Bugs in stato [glsa] </title>
<body>
<p>
Nello stato [glsa], il bug di sicurezza =C3=A8 stato corretto. Dobbiamo p=
ubblicare il
GLSA o semplicemente chiudere il bug senza GLSA. La policy determina in q=
uali
casi un GLSA =C3=A8 necessario e in quali casi non lo =C3=A8. Vi sono anc=
he isituazioni
nelle quali =C3=A8 necessario un voto per definire se un GLSA =C3=A8 nece=
ssario o meno. Se
almeno due membri del Team di sicurezza votano per "no GLSA", allora ness=
un GLSA
dovrebbe essere pubblicato. Il bug rimane in stato [glsa] finch=C3=A8 non=
viene
pubblicato il GLSA.
</p>
<p>
Quando =C3=A8 necessario un GLSA, ma non =C3=A8 stato pubblicato nulla, i=
l bug entra nello
stato [glsa+]. Questo =C3=A8 il caso in cui il coordinatore GLSA assegnat=
o 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 punt=
o e
finalizzare il GLSA.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Gestione delle vulnerabilit=C3=A0 dei bug "confidential" </title>
<section>
<title>Regole del pannello di stato(Status Whiteboard) </title>
<body>
<p>
I bug confidenziali dovrebbero seguire questo modello:=20
"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=C3=A0, 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 bug confidenziali:
</p>
<table>
<tr>
<th>Stato</th>
<th>Descrizione</th>
</tr>
<tr>
<ti>preebuild</ti>
<ti>Il maintainer del pacchetto specifico =C3=A8 stato chiamato a prepara=
re 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 u=
na
ebuild non ancora pubblica</ti>
</tr>
</table>
</body>
</section>
<section>
<title>Maneggiare bugs confidenziali</title>
<body>
<p>
I bugs semipubblici dovrebbero essere trattati come bug pubblici, a parte=
il
fatto che nessun gruppo di sviluppo o alias per le varie architetture dov=
rebbe
essere messo in CC tranne gli sviluppatori specifici per quel bug.
</p>
<p>
I bugs confidenziali e classificati richiedono maggiore attenzione. L'ebu=
ild ed
i files per correggere la vulnerabilit=C3=A0 NON dovrebbero essere aggiun=
ti al CVS
del portage, e nessun aspetto di quei bug dovrebbero essere discussi in
pubblico.
Patch o tarball di sovrascrittura del portage possono comunque essere all=
egati
al bug. I tester dovranno installare la propria tarball di overlay per te=
starla.
L'idea con questi bug =C3=A8 di preparare l'ebuild e farlo testare entro =
la data di
rilascio concordata, in modo tale da poterla rilasciare con tutte le keyw=
ord
necessarie insieme al GLSA nello stesso istante in cui il rilascio dell'e=
build
diventa pubblico.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Abozzare GLSA con GLSAMaker</title>
<section>
<title>Regole Generali</title>
<body>
<p>
Il GLSA dovrebbe utilizzare il nome del software colpito prestando attenz=
ione a
maiuscole/minuscole, non utilizzando, quindi il package name di Gentoo.
Per esempio, dovreste utilizzare "MySQL" e non "mysql". I nomi in minusco=
lo
dovrebbero essere utilizzati solo se il software ha un nome tutto in minu=
scolo o
se il software =C3=A8 identificato dal nome del suo comando (ad esempio
"traceroute").
</p>
<p>
Non dovreste copiare nessuna parte di una descrizione gi=C3=A0 esistente=
, ma potete
utilizzarle come fonti d'informazione per il GLSA. Se copiate, per esempi=
o una
descrizione di un software da un sito internet, per favore utilizzate una
citazione e le virgolette.
</p>
</body>
</section>
<section>
<title>Titolo, Sinossi, Keyword</title>
<body>
<p>
Il titolo deve essere corto (< 60 caratteri nella maggior parte dei c=
asi) ed
indicare il nome dell'applicazione (non la categoria). Dovrebbe consenti=
re
d'indentificare chiaramente la vulnerabilit=C3=A0 senza entrare nei detta=
gli. La
versione dovrebbe essere omessa, tranne nei rari casi in cui =C3=A8 perme=
sso
identificare un pacchetto pi=C3=B9 chiaramente. I pacchetti multipli colp=
iti
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=3Dheader_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 =C3=A8 una corta (< 160 caratteri) ma completa descrizione =
della
vulnerabilit=C3=A0 di quale effetto abbia. Gli esempi includono:
</p>
<table>
<tr>
<ti>Due utilities MySQL creano files temporanei con path hardcoded, conse=
ntendo
ad un attacker di utilizzare un link simbolico per ingannare MySQL nel
sovrascrivere dati importanti.</ti>
</tr>
<tr>
<ti>Vulnerabilit=C3=A0 multiple, inclusi buffer overflow eseguibili remot=
amente sono
stati rilevati nel codice comune tra Mplayer e la libreria xine</ti>
</tr>
</table>
<p>
La categoria delle keywords GLSA =C3=A8 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=C3=A0 loca=
li possono
essere gestite solo da un utente locale del sistema in questione. Per ese=
mpio
implica esguire uno script per elevare i privilegi, oppure accedere ad un=
a
directory temporanea per far partire un symlink attack. Le vulnerabilit=C3=
=A0 remote
sono quelle che possono essere eseguite da un attaccante con o senza un a=
ccount
sul sistema bersaglio. Le vulnerabilit=C3=A0 remote possono essere sia at=
tive
(sfruttando un server in ascolto per inviare codice maligno) o passive (a=
ttirare
un utente per collegare il software residente sul client ad un server "ma=
ligno"
o ad aprire files con codice analogo).
</p>
<p>
La severity =C3=A8 un'indicazione di quanto in profondit=C3=A0 arrivi la =
vulnerabilit=C3=A0.
Viene definita nella Vulnerability Treatment Policy, nella tabella "Evalu=
ate 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, s=
olo
quando si utilizza una specifica opzione di configurazione, teoricamente =
rimane
una severit=C3=A0 "Alta". Un DoS in tutte le configurazioni di Apache teo=
ricamente
resta serverit=C3=A0 "Normale". In rari casi la severity pu=C3=B2 esser=
e corretta,
quando molti membri del team di sicurezza sono d'accordo, verso un livell=
o pi=C3=B9
alto. Per esempio, una vulnerabilit=C3=A0 che consentisse il deface di u=
n sito
internet in Apache ed in tutte le configurazioni dovrebbe probabilmente e=
ssere a
severity "Alta" piuttosto che "Normale".
</p>
</body>
</section>
<section>
<title>Pacchetti vulnerabili, inalterati</title>
<body>
<p>
Questa sezione fornisce informazioni sulle versioni dei pacchetti che son=
o
rimasti inalterati o vulnerabili alla vulnerabilit=C3=A0 descritta nell'i=
nformativa
corrente. Dovreste prestare attenzione particolare a quei numeri, perch=C3=
=A8
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 mult=
iple
per architetture differenti se la descrizione della versione =C3=A8 diffe=
rente di
architettura in architettura. Il campo "Auto" deve essere impostato a "tr=
ue" se
il paccchetto =C3=A8 aggiornabile via emerge. Per i campi versione posson=
o esservi
molteplici casistiche.
</p>
<impo>
In questa sezione (e soltanto in questa sezione), le architetture dovrebb=
ero
essere scritte cos=C3=AC come compaiono nelle keyword (cio=C3=A8 "x86", "=
amd64",
"sparc", ...), e non in maiuscolo.
</impo>
<p>
Il caso pi=C3=B9 semplice si verifica quando la vulnerabilit=C3=A0 =C3=A8=
presente in tutte le
vecchie versioni ed =C3=A8 corretta in tutte le versioni pi=C3=B9 recenti=
rispetto alla
versione di una specifica correzione. In questo caso, dovreste usare
">=3D prima versione corretta" come inalterata e
"<=3D ultima versione colpita" come vulnerabile. Dovreste controllare =
pi=C3=B9 volte
che non esista un'ebuild fra l'ultima versione colpita e la prima version=
e
corretta. Qualora vi trovaste in dubbio, dovreste usare
">=3D prima versione corretta" come inalterata e
"<=3D prima versione corretta" come vulnerabile.
</p>
<p>
Un caso pi=C3=B9 complesso si verifica quando la vulnerabilit=C3=A0 si pr=
esenta soltanto
in alcune versioni recenti. Facciamo l'esempio di un pacchetto dove la ve=
rsione
1.2.8-r2 non =C3=A8 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 =C3=A8 stata corretta. In questo caso ci son=
o due
possibilit=C3=A0.
</p>
<table>
<tr>
<th>Inalterata</th>
<th>Vulnerabile</th>
</tr>
<tr>
<ti>>=3D1.2.10</ti>
<ti>=3D=3D1.2.9 =3D=3D1.2.9-r1 =3D=3D1.2.9-r2</ti>
</tr>
<tr>
<ti><=3D1.2.8-r2 >=3D1.2.10</ti>
<ti><1.2.10</ti>
</tr>
</table>
<p>
Per concludere, quando il pacchetto non ha una versione corretta, dovrest=
e
omettere l'opzione "inalterato" (unaffected) per quel pacchetto ed impost=
are
"Auto" a "no". =20
</p>
<impo>
Quando le versioni delle correzione sono complesse, dovreste controllare =
pi=C3=B9
volte che le versioni XML e TXT del GLSA elenchino correttamente le vostr=
e
versioni.
</impo>
</body>
</section>
<section>
<title>Background, Descrizione, Impatto</title>
<body>
<p>
La sezione Background fornisce le informazioni sul pacchetto a rischio. D=
escrive
brevemente cos'=C3=A8 e fornisce tutte le informazioni utili a comprender=
e la parte
del pacchetto vulnerabile. La sezione Background dovrebbe essere pi=C3=B9=
corta della
sezione di descrizione o della sezione impatto (Impact). Tra gli esempi d=
a
seguire includiamo: =20
</p>
<table>
<tr>
<ti>Il K Desktop Environement (KDE) =C3=A8 un potente ambiente grafico de=
sktop della
Free Software foundation. KDE usa gli URI handlers per innescare vari pro=
grammi
quando vengono ricevute delle URL specifiche.</ti>
</tr>
<tr>
<ti>
CVS (Concurrent Versions System) =C3=A8 un sistema open-source di control=
lo di
versione network-transparent. Contiene sia una client utility che un serv=
er.
</ti>
</tr>
<tr>
<ti>Metamail =C3=A8 un programma che decodifica la posta codificata MIME.=
Viene
quindi spesso automaticamente invocato quando una email viene letta o ric=
evuta.
</ti>
</tr>
</table>
<p>
La sezione "descrizione" descrive pi=C3=B9 in dettaglio qual =C3=A8 la vu=
lnerabilit=C3=A0 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=C3=A0, 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 sa=
rebbe
"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 con=
tenuti
del file saranno sovrescritti con'output delle informazioni del telnet tr=
ace. Se
MyFile non esiste, il file verr=C3=A0 generato nella home directory del=
l'utente.
</ti>
</tr>
<tr>
<ti>
L'utility di bug reporting di MySQL (mysqlbug) genera un file temporaneo =
per
loggarvi i bug report. Un utente locale "maligno" con diritti di scrittur=
a 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 genera=
sse
l'ennesimo file di log, finirebbe con il sovrascrivere l'obiettivo (nel n=
ostro
esempio, /etc/passwd). Una vulnerabilit=C3=A0 simile esiste con la mysql_=
multi
ultility, che genera una file temporaneo denominato mysql_multi.log.
</ti>
</tr>
<tr>
<ti>Vulnerabilit=C3=A0 multiple sono state scovate e riparate nell'RTSP =
che gestisce
il codice in comune alle versioni recenti di questi due pacchetti. Queste
vulnerabilit=C3=A0 includono parecchi buffer overflow sfruttabili da remo=
to.</ti>
</tr>
</table>
<p>
La sezione "Impact" descrive l'effetto globale delle vulnerabilit=C3=A0 d=
escritte
nella sezione "descrizione", una volta sfruttate. Dovrebbe focalizzarsi s=
ul
massimo rischio possibile. Buoni esempi sono:
</p>
<table>
<tr>
<ti>
Un attaccante remoto, presentandosi come RTSP stream server, pu=C3=B2 ese=
guire 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
attaccante pu=C3=B2 attirare un utente per usare un URL "maligna" o una p=
laylist per
ottenere lo stesso identico risultato</ti>
</tr>
<tr>
<ti>
Questo exploit ha due possibili effetti. In primo luogo, pu=C3=B2 generar=
e nuovi
files nella home directory dell'utente. In secondo luogo, e molto pi=C3=B9
pericoloso, pu=C3=B2 sovrascrivere i files 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 files impor=
tanti
salvati in quella directory.
</ti>
</tr>
</table>
</body>
</section>
<section>
<title>Workaround, Soluzione</title>
<body>
<p>
Il workaround descrive se esiste una qualsiasi maniera semplice (tranne
l'aggiornamento alla versione di correzione) per evitare di essere vittim=
e della
vulnerabilit=C3=A0. I buoni esempi includono:
</p>
<table>
<tr>
<ti>
Come workaround provvisorio, bypassando il supporto del Kerberos 4, potre=
ste
spegnere il kadmin del Kerberos 4 facendo partire il kadmind con l'opzion=
e
<c>--no-kerberos4</c>.</ti>
</tr>
<tr>
<ti>Ad oggi non esistono workaround conosciuti.</ti>
</tr>
</table>
<p>
La sezione "Risoluzione" spiega nei termini human-readable che cosa dovet=
e fare
per completamente essere protetti dalla vulnerabilit=C3=A0. Questa sezion=
e deve
assomigliare a questa: =20
</p>
<pre caption=3D"Esempio di risoluzione">
Tutti gli utenti di Heimdal dovrebbero effettuare l'upgrade all'ultima ve=
rsione stabile:
<code>
# emerge --sync
# emerge --ask --oneshot --verbose ">=3Dapp-crypt/heimdal-0.6.2"
</pre>
<p>
Qualora vi fossero pi=C3=B9 architetture, dovrebbe assomigliare a questa
</p>
<pre caption=3D"Esempio multi-architettura">
Gli utenti di OpenOffice.org su SPARC dovrebbero:
<code>
# emerge --sync
# emerge --ask --oneshot --verbose ">=3Dapp-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 ">=3Dapp-office/openoffice-1.0.3-r1=
"
</pre>
<p>
Se il GLSA riguarda una libreria condivisa, dovreste includere il seguent=
e
paragrafo all'estremit=C3=A0 della sezione "risoluzione" per avvisare cir=
ca la
necessit=C3=A0 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=C3=A0 in questione. Quando un numero
CVE (CVE-xxxx-xxx) =C3=A8 disponibile, dovrebbe essere fornito (con il nu=
mero CAN
completo in "Title"). Potete anche collegare uno advisory di uno sviluppa=
tore
upstream e/o un'email announce, quando disponibili. Dovreste evitare link=
s ad
advisories di altre distribuzioni o advisories non ufficiali provenienti =
da
entit=C3=A0 esterne.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Pubblicazione GLSA </title>
<section>
<title>Peer reviewing</title>
<body>
<p>
Quando la bozza iniziale =C3=A8 pronta, deve essere sottoposta alla revis=
ione degli
altri membri del team di sicurezza, effettuando una richiesta di revision=
e sul
canale #gentoo-security. La versione finale (dopo che tutte le correzioni=
sono
state applicate) deve essere approvata da due membri del team di sicurezz=
a 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 sia=
no
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 =C3=
=A8
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 vera=
mente
una vulnerabilit=C3=A0 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 ufficia=
le
GLSA. Ci=C3=B2 viene fatto chiamando la funzione "Move" in GLSAMaker per =
spostare la
bozza dalla zona di sviluppo alla zona ufficiale. =20
</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 compa=
ia
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: =20
</p>
<pre caption=3D"Aggiornamento 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 dovreste cliccare<c>Fetch</c> nel GLSA per scaricare la ve=
rsione
XML, e salvarla nella vostra gentoo_cvs/gentoo/xml/htdocs/security/en/gls=
a/
directory. A questo punto dovreste effettuare il commit ed aggiungere il =
file
XML:
</p>
<pre caption=3D"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>E-mail announcement</title>
<body>
<warn>
Ogni volta che usate un nuovo setup (software o macchina) per inviare un
annuncio GLSA, dovreste far s=C3=AC 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) sembr=
i
corretta, 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=
=C3=A0 qui"
(dovreste copiare/incollare dal titolo nel file di testo)</li>
<li>Il corpo della mail dovrebbe corrispondere al contenuto del file di t=
esto,
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 =C3=A8 rich=
iesta
moderazione. Basta rispondere a questa mail e l'email announce precedente=
mente
detta arriver=C3=A0 a destinazione.
</note>
</body>
</section>
<section>
<title>Chiusura dei bug</title>
<body>
<p>
Dovreste controllare che la mail sia arrivata a gentoo-announce, poi pote=
te
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 st=
iamo
parlando di un aggiornamento. Quando la policy garantisce una ripubblicaz=
ione
dovrebbero essere seguite queste linee guida: =20
</p>
<ul>
<li>
Il campo revisione dovrebbe essere correttamente impostato in XML.=20
Ci=C3=B2 significa che la revisione potrebbe avere bisogno di di essere c=
orretta
manualmente nella directory data di GLSAMaker, se fate cambiamenti multip=
li
usando GLSAMaker (es. <revised>September 10, 2004: 02</revised&g=
t;)</li>
<li>Se non sussiste vulnerabilit=C3=A0 nessun pacchetto colpito dovrebbe=
essere
elencato nell'XML</li>
<li>Il titolo pu=C3=B2 cambiare (es. GLSA 200409-14 per Samba e GLSA 2004=
11-01 per
ppp)
</li>
<li>Non tutti gli Errata richiedono ripubblicazione. La policy spiega
dettagliatamente quando la ripubblicazione =C3=A8 necessaria.</li>
<li>
Per la versione di testo GLSAmaker pu=C3=B2 aggiungere le informazioni re=
lative agli
aggiornamenti ed alle errata. Si seguano manualmente le istruzioni fornit=
e da
GLSAmaker.</li>
<li>
La versione testuale deve contenere la sezione degli aggiornamenti o dell=
e
errata (si veda l'esempio indicato sotto) e soltanto DOPO QUESTO solo sez=
ioni
vengono cambiate (la versione XML non ha sezioni aggiuntive)</li>
</ul>
<table>
<tr>
<ti>
Questo advisory =C3=A8 stato descritto via ppp in maniera non corretta co=
me
vulnerabile ad un DoS. Dopo ulteriori verifiche, sembra che un utente rem=
oto
possa negare soltanto il servizio a s=C3=A8 stesso, quindi questo bug non=
induce
alcun problema di sicurezza. Le sezioni corrette compaiono qui sotto.</t=
i>
</tr>
</table>
<p>
Ecco due esempi completi di errata email, si veda<uri
link=3D"http://archives.gentoo.org/gentoo-announce/msg_02598.xml">ERRAT=
A:
[ GLSA 200409-14 ] Samba: Remote printing non-vulnerability</uri>
(dove non c'era nessuna vulnerabilit=C3=A0) e <uri
link=3D"http://archives.gentoo.org/gentoo-announce/msg_02502.xml">ERRAT=
A:
[ GLSA 200405-25 ] Tla: Multiple vulnerabilities in included
libneon</uri> (dove il problema non era stato corretto in maniera effic=
ace
nella versione iniziale). Per un esempio di update, si veda <uri
link=3D"http://archives.gentoo.org/gentoo-announce/msg_02663.xml">UPDAT=
E:
[ GLSA 200410-30 ] GPdf, KPDF, KOffice: Vulnerabilities in included
xpdf</uri> (dove la correzione ha introdotto un'altra vulnerabilit=C3=A0=
).
</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> =20
<li><uri link=3D"http://dev.gentoo.org/~koon/packageview/">packageview</u=
ri>
=C3=A8 un tool che aprir=C3=A0 packages.gentoo.org e Gentoo ViewCVS nel =
punto giusto per
una categoria e una nome pacchetto assegnati. Aiuta a determinare quali k=
eyword
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=3D"http://dev.gentoo.org/~koon/glsacommit.txt">glsacommit</=
uri> =C3=A8
una funzione bash che si occupa l'handling GLSA committing. Caratterizzat=
o
dall'ssh-agent keyadding, glsa-check controlla pi=C3=B9 volte la conformi=
t=C3=A0 ed ha
delle "Are you sure" funzioni. Editatelo per soddisfare le vostre necessi=
t=C3=A0 e le
posizioni delle directory .</li>
</ul>
</body>
</section>
</chapter>
</guide>
--=-8nd3SbOYQ7HC/lflRjXn--
--
gentoo-docs-it@gentoo.org mailing list