Il seguente aneddoto non ha un valore generale:
Nel 1999, ho preso il codice sorgente per PGP (non GnuPG, ancora nella sua infanzia), versione 5.5, e lo ho compilato sulla mia macchina (che era un Alpha che eseguiva NetBSD, cioè un sistema Unix piuttosto "normale"). Il codice sorgente di PGP era disponibile da parecchi anni ed era spesso propagandato come necessariamente sicuro dal momento che era open source.
Naturalmente, ho quasi subito incontrato bug. Ho guardato la fonte, e ho scoperto che:
- Il codice utilizzava il tipo
char come se non fosse firmato e, in quanto tale, era completamente incapace di elaborare correttamente qualsiasi carattere oltre il set ASCII a 7 bit. Era così per tutto il codice.
- Il codice sorgente era diverso centinaia di file sorgente, in più di 30 sottodirectory (e sottodirectory).
Quindi sono arrivato alla conclusione che, nonostante fosse un obiettivo di alto profilo, con codice sorgente aperto per ispezione per diversi anni (il codice sorgente era stato anche stampato come un libro per aggirare i regolamenti di esportazione degli Stati Uniti di quel tempo), nessuno in effetti si è preso la briga di guardarlo (o chi lo ha fatto, non possedeva abbastanza conoscenza in C per farlo correttamente).
Il codice non ha reso facile la verifica; il codice di controllo è già un compito abbastanza noioso che difficilmente i dilettanti non pagati possano affrontare da soli. È molto più interessante, per il dilettante, riscrivere il tutto da zero, che è esattamente quello che è successo (con GnuPG ).
Anche se non credo, in generale, in orde di revisori amatoriali non nominati che controllano il codice semplicemente perché è lì, ci sono sono progetti che raccolgono un po 'di revisione, soprattutto a causa delle persone che vogliono per modificare il progetto in base alle proprie esigenze. Pertanto, alterazioni dannose degli strumenti di sicurezza sono una cosa rischiosa. Ciò che troverai in tutti i progetti, open source o meno, correlato alla sicurezza o meno, sono bug , alcuni dei quali sono sfruttabili per comportarsi a vantaggio di terze parti (ad es. Vulnerabilità ) ).
Il modo plausibile per iniettare una backdoor in strumenti di sicurezza open source è di creare un'implementazione onesta o un errore di progettazione, in particolare quando si ha a che fare con PRNG (ci sono state alcune accuse, apparentemente infondate, di una tale backdoor in OpenBSD; vedi questa risposta ; la backdoor non c'era, ma tutti hanno preso la cosa seriamente, perché è plausibile ).
Su una base puramente teorica, l'audit esterno può scoprire tutte le backdoor esattamente quanto può scoprire tutti i bug nel codice controllato, cioè non può.