Re: Debian va contro il suo contratto

On Thu, Jan 24, 2002 at 12:37:14AM +0100, antirez wrote:
> > Qualche esempio: OpenBSD (che non puo' certo vantarsi di avere sempre le
> > ultime versioni di tutto), Linux (la cui 2.0.38 per molti versi e' da
> > considerarsi piu' sicura delle 2.4.x), Qmail (che non viene aggiornato da
> > secoli per il semplice fatto che non ha bisogno di correre alla ricerca
> > di nuove features, per ora sta benissimo cosi'), and so on.
> 
> Concordo, la mia parafrasi e':
Mi associo al filone del "datato è bello" se cerchiamo stabilità e sicurezza.

> non mettere mai codice che non e' davvero necessario in una
> applicazione che vuole essere sicura
Questa nn l'ho capita. Intendevi codice che nn aggiunge features a
quell'applicazione? E se sì... allora perchè lo scrivi?

> rendere l'applicazione una serie di moduli con una interfaccia
> definita che interagiscono tra loro in maniera piu' semplice
> possibile
Su questo ti do' ragione a pieno. Anke se è dannatamente difficile sviluppare
qualcosa che risulti coerente nella sua struttura anke dopo qualke rilascio.
Penso ai miei tools che a volte assomigliano ad un'accozzaglia di codice.

> Mentre ci sono volevo chiedere qual'e', a vostro avviso, il
> miglior modo per fare un security auditing di codice nuovo.
> Secondo voi e' meglio scrivere tentando di non fare errori
> e fare un security auditing finale prima di rilasciare la
> prima versione per il pubblico o fare l'auditing in maniera
> parallela allo sviluppo?

Secondo me fare l'auditing parallelamente. Ad esempio aggiungi la funzionalità
A e stressi l'applicazione per vedere se il nuovo modulo ha delle falle e così
via per cio' che aggiungi fino alla release finale. E' vero che sprechi
risorse ma alla fine ti trovi l'applicazione finale gìa' testata. IMHO.

Ciao :)
-- 
$>cd /pub
$>more beer

(0>
//\  Perego Paolo <p_perego@modiano.com> - www.sikurezza.org/angel
V_/_ 'It's seems the hardest life I've never known'
I'm Linux drow 2.4.16-4GB - SuSE Linux 7.3 (i386) powered.

PGP signature