[Discussioni] [NEWS] No Defense for Linux

[Marco Ermini]

<quota chi="Simo Sorce">
> On Thu, 2004-07-29 at 09:09, Marco Ermini wrote:
>> Una distro - tanto più RH o SuSE, che hanno decine di migliaia di
>> /clienti
>> paganti/ - inserisce nei suoi kernel unicamente i moduli per i driver
>> che
>> sono in grado di supportare attivamente, e comunque escludono a priori
>> tutti quelli che sono "dubbi" da un qualche punto di vista (come è stato
>> per il supporto NTFS).
>
> Avendo esperienza diretta come cliente pagante so che fanno anche loro
> le loro belle supidate, e ho sempre trovato i driver esoterici _prima_
> nelle distro blasonate e solo dopo (a volte molto dopo, vedi reiserfs o
> xfs che non sono manco esoterici) nei kernel vanilla.
</quota>

Avendo esperienza diretta con gli sviluppatori che lavorano sulle versioni
rawhide, so che magari fanno le loro belle stupidate come tutti (ma
francamente discutere di kernel con Alan Cox o dire allo stesso che fa
delle stupidate, è come se tu volessi discutere dii buchi neri con
Hawkins... francamente tra te ed Hawkins, senza offesa, so chi scegliere
;-), ma driver "esoterici" non ne mettono: come è intuibile e - spero -
facile da comprendere :-) mettono unicamente driver per periferiche che
ritengono di essere in grado di supportare.

Quando tu vedi driver che non sono ancora ufficialmente nei kernel, li
consideri "vanilla"... ma in realtà stanno semplicemente cercando di
conciliare l'esigenza di supportare hardware di ultima generazione o
esigenze della propria utenza con lo sviluppo "ufficiale" che è ovviamente
e giustamente più "attento" e subisce un processo di revisione più lento.

Tieni presente che una buona percentuale di coloro che sviluppa
direttamente sul kernel è al soldo di queste due distro, e che comunque
queste distro lavorano direttamente con i produttori di hardware, per cui
penso che siano perfettamente in grado di fare questo lavoro.

(Per inciso, è molto più "vanilla" ReiserFS, che ha mostrato nel tempo dei
bug grossi come case, che non il supporto per le ACL estese di ext3 - ext3
che poi a ReiserFS ha ben poco da invidiare... anzi. Ma qui si entra nelle
FAQ sul kernel e non è questa la lista giusta.)


>> Faccio presente che per vari problemini, nei 2.6 di
>> Fedora Core 2 attualmente è stato rimosso persino il driver ide-scsi...
>
> ide-scsi non c'è perchè non serve più è superato.

Non nè corretto, come ha riportato oggi Alan Cox (RedHat...) è una
dipendenza necessaria per diversi device come i nastri IDE ed è stato un
errore della FC2 rimuoverlo, verrà reimplementato nelle prossime release
(anche se non nella FC3 ormai).


> Secondo me in linea di principio un "infiltrato" lo si può
> tranquillamente infiltrare anche nel processo di sviluppo del kernel
> linux, dati tempo, talento e determinazione.

Verrebbe comunque rintracciato, il suo codice è comunque sottoposto ad un
review - se non ad un vero e proprio auditing -, e quindi verrebbe comuque
smascherato nel brevissimo periodo. Se poi la sua periferica non è
supportata dalle distro, il suo codice non verrà comunque distribuito, e
se viene supportato dalle distro viene comunque rivisto dai "kernel
hacker" delle distro stesse.

Praticamente, è un processo molto difficile. IMHO /forse/ è più facile che
avvenga in distro non commerciali e più "open" che non in RH o SuSE, ma
tutto sommato ho dei seri dubbi che possa finire "impunito" anche in
distro come Debian.


> Quello che non dice il signor O'Dowd invece è che con il software
> sviluppato ""negli US"" ovvero spesso subappaltato offshore ad indiani,
> russi e altri è molto, ma molto più facile inserire codice maligno.

Certo, ma non vedo spazio per degli sviluppi potenzialmente candidati al
kernel di Linux. Per i motivi di cui sopra, vedo anche molto difficile che
certa roba possa finire in userspace.

Concorderai come me che appare molto di più un argomento contro il
software closed source che non quello free...


Ciao.
-- 
Marco Ermini
http://www.markoer.org
Dubium sapientiae initium. (Descartes)
root a human # mount -t life -o ro /dev/dna /genetic/research
<< This message is for the designated recipient only and may contain
privileged or confidential information. If you have received it in
error, please notify the sender immediately and delete the original.
Any other use of the email by you is prohibited. >>