Recentemente alcune persone hanno notato uno strano cambiamento nel codice sorgente del kernel Linux, poi durante la revisione del codice del kernel su GitHub Hanno notato che le modifiche apportate da terze parti (coloro che hanno clonato o biforcato questo) apparivano stranamente nel repository principale.
Questo ha attirato l'attenzione di alcuni sull'interfaccia GitHub quando è stata rivelata una funzionalità interessante che consente di presentare eventuali modifiche di terze parti come una modifica già inclusa nel progetto principale.
Ad esempio, oggi nei social network ha cominciato a diffondersi un riferimento ad un cambiamento nel mirror ufficiale del repository principale del kernel Linux, indicando la sostituzione di una backdoor nel driver HID-Samsung.
Una stranezza di GitHub ha allarmato gli sviluppatori del kernel
Di fronte a questo conflitto alcuni hanno iniziato a controllare il codice del kernel soprattutto nel driver Samsung oltre a provare a verificare se la sicurezza del kernel fosse stata compromessa.
L'analisi della situazione lo ha dimostrato GitHub, per ottimizzare l'archiviazione e ridurre al minimo la duplicazione dei dati sui propri server, archivia tutti gli oggetti dal repository principale e le filiali ad esso associate, condividendo logicamente la proprietà dei commit.
dopo di che Questa memoria consente a chiunque stia navigando all'interno del codice di vedere qualsiasi conferma da qualsiasi fork in qualsiasi repository associato, indicando esplicitamente il suo hash nell'URL.
Ad esempio, nel caso di una demo backdoor, uno degli utenti ha creato un fork del repository principale del kernel Linux nell'interfaccia GitHub, quindi ha aggiunto un commit con codice simile a una backdoor al suo fork.
Successivamente, ha formato un collegamento in cui l'identificatore SHA1 della modifica esterna è stato sostituito nell'URL del repository principale.
Quando viene aperto un collegamento simile, un commit esterno viene visualizzato nell'interfaccia GitHub nel contesto del repository principale, anche se è stato eseguito sul fork e non ha nulla a che fare con il repository principale e non è presente alcun commit di questo tipo.
Inoltre, Nell'interfaccia GitHub, durante la visualizzazione del log delle modifiche per i singoli file, il repository principale mostra anche commit di terze parti, il che crea molta confusione.
Questo ha allarmato alcuni perché pensavano che si trattasse di un hack e di aver introdotto codice dannoso nel codice sorgente del kernel Linux.
Ebbene, come possiamo vedere a prima vista nell'immagine, sembrerebbe che il codice inserito faccia parte di quanto memorizzato nel repository principale del Kernel Linux.
E che all'inizio non fa riferimento ai repository esterni in cui sono state apportate le modifiche.
Era tutto un falso allarme
Questo "errore" (si fa per dire) preoccupava molti, perché al momento non sapevano se stavano già correndo dei rischi o se l'integrità del Kernel era stata compromessa.
Passo poco tempo così si sarebbero resi conto che durante l'estrazione dei dati o la clonazione di un repository utilizzando i comandi git, mancavano le modifiche di terze parti nel repository risultante.
GitHub ha semplicemente presentato le modifiche a colpo d'occhio quando in realtà non lo è.
Momento non si sa più nulla e se il popolo di Github (Microsoft) ha in mente di dare una soluzione a questo, che non influisce direttamente sullo sviluppo, tanto meno quando si ottiene il codice sorgente del kernel.
Ma cosa succede se può confondere molti che scelgono di rivedere alcune parti dei progetti archiviati su Github.
Bene, non è qualcosa che viene mostrato direttamente nel codice del kernel Linux, ma verrà mostrato anche nei fork o nei fork di altri progetti.
Quindi è possibile che molti sviluppatori o utenti di questa piattaforma abbiano già inviato alcune email alle persone di GitHub.
Se vuoi saperne di più su questo argomentopuoi visitare il seguente collegamento dove è ancora mostrato il codice che ha formato questa situazione e anche i commenti al riguardo a questo proposito qui.