Re: Debian va contro il suo contratto

~ non mettere mai codice che non e' davvero necessario in una
~ applicazione che vuole essere sicura
e non ci sono dubbi

~ rendere l'applicazione una serie di moduli con una interfaccia
~ definita che interagiscono tra loro in maniera piu' semplice
~ possibile
e questo in casi disperati come l'uscita di un nuovo attacco sarebbe una
soluzione per escludere il problema fino al rilascio di una patch

~ Siete d'accordo?
si si 

~ 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 dipende se intendi un auditing fatto dall'autore stesso o da un
altro esperto in materia.

nel caso sia lo stesso, tanto vale far auditing parallelamente allo sviluppo
di ogni modulo o pezzo o funzione significativa, in modo da poter rianalizzare
ancora a mente calda la sequenza del codice e poter farcire di commenti le 
precazioni di sicurezza (in modo da poter notare x un futuro controllo
cos'ha controllato e cosa sicuramente non si puo verificare e vedere cosa 
non ha controllato + rapidamente)

se invece si tratta di un altro programmatore (imho molto meglio, dal momento
che se uno e` abituato male a far qualcosa o commette un certo tipo di 
sbaglio abituato a non notare ... uno con altre abituini ha sicuramente +
possibilita` di individuar l'errore) ritengo sia indifferente ma far auditing
alla fine e` meglio nel complesso (non si analizzan solo dei pezzi ma si
puo far un confronto generale che parallelamente non puoi fare ... tipo la 
modifica di variabili globali, race condition, signal handler mal gestiti)
anche se + faticoso dal momento che si analizza un intero codice non proprio.

~ In teoria, se applicati bene, ambedue gli approcci dovrebbero
~ funzionare, ma ho la sensazione che il secondo (auditing parallelo)
~ sia uno spreco di risorse.
il caso di openbsd/openssh xo` dimostra che sono differenti ...
tutti i binari di obsd sono stati sottoposti ad auditing dopo esser stati
sviluppati, openssh e` stata programmata dal team che ha fatto l'auditing
(quindi auditing in parallelo) eppure openssh e` il demone che ha presentato
+ bachi negli ultimi anni *tra quelli inseriti in openbsd*

forse ho cattive informazioni ma quello che ricordo e ho visto e` proprio
questo ... smentite o che ne pensate ?

ciao ciao

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List