Disponibili anche per Testing (Etch) le patch per la sicurezza

Lun, 26/09/2005 - 20:12

Disponibili anche per Testing (Etch) le patch per la sicurezza

Inviato da erbogasto 1 commento

Il team per la sicurezza del ramo testing (Debian Testing Security Team)ha annunciato il supporto per la sicurezza per la distribuzione in fase testing (etch).
Questo significa che si potranno applicare le patch per la sicurezza ,come gia' avviene per il ramo Stable (Sarge),semplicemente aggiungendo al proprio APT-Sources.list i repository per la sicurezza come consigliato nella Notizia Ufficiale.


In:



Commenti

Ritratto di eregil
#1

Inviato da eregil il Mar, 27/09/2005 - 19:26.

Re: Disponibili anche per Testing (Etch) le patch per la ...

C'è sicuramente da spendere qualche parola in più su secure-testing.

A chi interessano questi aggiornamenti conviene visitare la home page relativa e da lì visitare la pagina della mailing list degli annunci, per leggere l'archivio e, se si vuole, iscriversi.

Sebbene a quanto sembra questo progetto sia stato testato per un certo periodo di tempo prima di essere lanciato questo mese, a me sembra che ci siano ancora delle cose da migliorare. L'ultimo aggiornamento di clamav tramite secure-testing per esempio è tuttora solo su etch-proposed-updates/security-updates (e non etch/security-updates) sul repository indicato dalla notizia e sui mirror, perciò ho dovuto aggiornare le mie fonti per installarlo da synaptic. La cosa curiosa è che l'annuncio in mailing list specificava di usare etch-proposed-updates, perciò ora sono nel dubbio che non si tratti di un caso isolato, il che renderebbe già obsolete le informazioni in home page (!).

Secure-testing IMHO è arrivato un po' troppo tardi. Per carità, non che voglia bacchettare il team, so benissimo quanto sia difficile mettere in atto un progetto di questo genere, ed evidentemente prima non si poteva.

Però secure-testing ovviamente ha finalità e modalità di gestione diverse dal repo "security" di stable: il team di sicurezza di stable sa benissimo che gli aggiornamenti entrano solo tramite il loro lavoro, in testing invece la via ordinaria è che entrino da sid dopo la quarantena (spesso ridotta a 2 giorni per gli aggiornamenti che includono patch di sicurezza), pertanto la finalità del team di secure-testing è quella di "attivarsi" se ci sono ragioni per cui un fix non entra da sid, per qualsivoglia ragione.

In certi casi questa ragione sono le dipendenze non soddisfatte in testing, e allora il ricorso a secure-testing si rende necessario. A volte però il motivo è più banale, come un pacchetto non compilato su tutte le architetture, e allora sarebbe più opportuno risolvere tali problemi per sveltire il passaggio del pacchetto da sid...

Purtroppo è capitato che quando etch aveva più bisogno di aggiornamenti di sicurezza mirati, perché quelli da sid non entravano per via di glibc ancora vecchio e xorg non presente in testing, secure-testing non esisteva; ed esiste ora che, potenzialmente, più aggiornamenti possono entrare per le vie ordinarie (ci sono ancora transizioni da terminare, come kde, ma questa sicuramente blocca meno pacchetti di glibc!).

Il recente intasamento di stable security a causa dell'aggiornamento di xfree86 in woody e sarge, con annesso annuncio che questo è capitato "mentre già si pensava di migrare da un server unico a un insieme di mirror" per gli aggiornamenti di sicurezza, mi fa pensare che secure-testing sia stato creato proprio con l'intento di testare una soluzione per aggiornamenti di sicurezza basata su un insieme di mirror... perché secure-testing.debian.net non è un server centrale come security.debian.org, ma redirige su uno dei mirror partecipanti al progetto... controllate l'home page che ho linkato sopra Wink

Quantunque l'avvio di secure-testing non sia stato del tutto roseo, devo convenire che ci sono buone premesse per un miglioramento generale di debian. Se il test di un insieme di mirror per la sicurezza andrà a buon fine e anche stable security adotterà questo modello, si eviterà che si ripetano inconvenienti come quelli recenti con xfree86; e se dovesse di nuovo capitare che molti aggiornamenti non riescano ad entrare in testing per vie ordinarie, gli utenti di testing "pura" non potranno che trarre beneficio dall'esistenza di secure-testing.

Buona debian a tutti. Laughing