Ciao Giacomo, Giacomo Tesio <giacomo@tesio.it> writes: [...]
Hai sentore che ci possa essere la possibilità che in questo scenario sia possibile nascondere adeguatamente bene qualche backdoor in GCC?
È complicato. :-(
Lo so: *complicato*, non solo complesso :-O
Non tanto in GCC, quanto nel software compilato con esso.
Sì sì, intendevo quello
E non tanto una bella backdoor fatta e finita, quanto vulnerabilità exploitabili in un determinato contesto.
OK chiaro: su questo avrei delle cose da dire in merito alla qualità dei linguaggi di programmazione ma sono questioni da tecnici e non voglio iniziare un flame pesante in questa lista.
E non sarebbe necessario inserire attivamente questo tipo di vulnerabilità, ma avervi accesso privilegiato, prima che vengano scoperti e sfruttati da altri come zero-day.
Considerato che il presupporto è che i binari del GCC non siano attivamente alterati senza che il relativo codice sorgente venga pubblicato (questione ancora non del tutto risolta, comunque), direi che siccome il codice sorgente di tutto il software libero *copyleft* _distribuito_ (GCC ad esempio) è disponibile allora io non vedo come chiunque possa trarre il vantaggio strategico di essere in grado di individuare gli zero-day prima degli altri; casomai chiunque potrebbe scoprirli e NON aprire un report CVE per sfruttare la cosa a proprio vantaggio, ma questo vale davvero per chiunque; sbaglio? Comunque, siccome la questione della garanzia che i binari usati come binary-seeds di intere distribuzioni non siano attivamente alterati NON è del tutto risolta, io (mica solo io) spenderei un po' di attenzione anche in quella direzione. [...]
Ma il tipo di influenza che Google&friends hanno su GCC tramite i loro impiegati è molto più sottile e complessa:
[...]
Tutte le comunicazioni private della Steering Committee sono accessibili a Google, IBM e Red Hat...
Cosa può andare storto?
Infatti io obbligherei lo steering committee a rendere pubbliche tutte le comunicazioni che riguardino le persone quando le comunicazioni sono effettuare nelle loro funzioni all'interno dello steering committee :-D Poi ognuno è libero di avere i propri segreti. [...]
Inizio a pensare che bisogna ripartire letteralmente da zero.
Io ne sono convinto da tre anni ma le risorse sono praticamente tutte impiegate per continuare a rappezzare cose ormai logore; che poi, per carità, non si può buttare via tutto da un giorno all'altro, però nemmeno continuare in sæcula sæculorum a scrivere cose che *per forza* contengono buffer-overflow e disgrazie del genere... ops, stava per partirmi il flame :-(
Il software deve essere leggibile da tutti.
O perlomeno ci dovrebbero essere un numero sufficiente di persone messe nelle condizioni di poterlo analizzare per svolgere quel lavoro di continua verifica collaborativa che *dovrebbe* essere uno dei veri vantaggi *cooperativi* (NON competitivi) del software libero e open source; invece quelli che lo fanno sono (percentualmente) pochissimi... e non solo perché non sono capaci di comprenderlo ed eventualmente criticarlo per la sua inutile complicazione ma soprattutto perché quel "mestiere" costa tanto e - AFAIU IANAL IMHO - NON "fa reddito". "The maintainers" [1] meriterebbero di essere considerati meglio, in particolare una volta che si fanno i conti con "The Innovation Delusion". [1] https://themaintainers.org/about-us [...]
C'è qualcuno addetto alla nostra cybersicurezza nazionale che se ne sta occupando o va tutto bene così, "solo" perché noi stiamo dalla parte di quelli che sono più bravi a inserire backdoors?
Ma figurati! :-D
Ero retorico :-D [...]
E non solo in Italia!
Ma certo, *tutti* credono di essere più bravi di altri a inserire backdoors. Ciao, Giovanni. [...]
[1] trovi i link su https://gcc.gnu.org/pipermail/gcc/2021-April/235303.html
-- Giovanni Biscuolo