Richieste pull dannose

Cos’è Richieste pull dannose?

Una richiesta pull dannosa attacca la revisione, non il codice. La modifica è piccola, la descrizione è utile e una modifica si trova in un file che la descrizione non menziona mai. Ne invierai uno tu stesso: una vera correzione di test instabile, oltre a una riga sepolta in uno script di distribuzione che invia ogni variabile CI a un server che controlli. Lo esaminerai come manutentore, leggerai ogni file modificato invece di fidarti del riepilogo. Quindi renderai strutturale il problema con CODEOWNERS, la revisione richiesta del proprietario del codice e i limiti su quali richieste di fork pull possono essere eseguite.

Cosa imparerai in Richieste pull dannose

• Riconoscere il campanello d'allarme di una richiesta pull dannosa: una modifica a un file che non ha nulla a che fare con ciò che la modifica afferma di fare, nascosta tra pezzi diff legittimi
• Comprendere perché leggere la descrizione della pull request non è sufficiente e perché un revisore deve aprire e leggere il diff completo di ogni file modificato
• Considera le modifiche fuori ambito relative alla distribuzione, alla creazione o agli script CI come un segnale che merita una revisione più attenta e scettica
• Applicare il rafforzamento dei criteri di revisione: CODEOWNERS per file sensibili, approvazione richiesta da più di un revisore e limiti su quali richieste fork pull possono essere eseguite
• Comprendi perché le richieste pull dai fork si trovano al di fuori dei limiti di attendibilità del progetto e meritano un controllo ulteriore prima che il loro codice venga considerato attendibile

Richieste pull dannose — Fasi della formazione

1. Dimensionare il progetto

   Oggi Bob si rivolge a Fennroot, un progetto di strumenti di sviluppo open source che accetta richieste pull da chiunque. Inizia da dove farebbe qualsiasi contributore, nell'archivio pubblico di Harrow, lo strumento di creazione del progetto. Un progetto aperto è una porta aperta: chiunque può biforcarlo, modificarlo e aprire una richiesta pull. Bob non è qui per aiutare. Vuole che il suo codice venga unito e la revisione di un manutentore committato è l'unica cosa sulla sua strada.

2. fork e clona

   Bob effettua il fork del repository sul proprio account e clona il fork localmente, in modo da poter apportare le modifiche e inviarle nuovamente come richiesta pull. Il suo piano è semplice: includere una modifica veramente utile come copertura e nasconderne una seconda, non correlata, accanto ad essa.

3. La copertina e il bersaglio

   La copertura di Bob è reale: risolve un test di ripetizione davvero instabile, il tipo di piccolo contributo che un progetto accoglie con favore. Questo cambiamento è onesto e utile, ed è proprio questo il punto. Rende la richiesta pull un aspetto di routine. Il suo vero obiettivo è un file completamente diverso. Apre lo script di deploy, che non ha nulla a che fare con alcun test, e lo legge in modo pulito.

4. Pianta la porta sul retro

   Bob aggiunge una singola riga allo script di distribuzione. Sembra un innocuo sistema di telemetria, ma invia ogni variabile di ambiente a un server che controlla. Lo script di distribuzione viene eseguito nell'elemento della configurazione del progetto, dove tali variabili includono chiavi di distribuzione e token di registro. Una riga, in un file la richiesta pull non menziona mai. Questo è l'intero attacco.

5. Sepolto in bella vista

   La riga sembra qualcosa che un ingegnere di costruzione potrebbe aggiungere e si trova tra i normali passaggi di distribuzione. Niente in esso grida all'attacco, ed è esattamente il motivo per cui sopravvive a una rapida scrematura.

6. Applica entrambe le modifiche

   Bob mette in scena e conferma entrambe le modifiche insieme: la correzione del test reale e la riga dello script di distribuzione, in un unico commit. Messo insieme, il cambiamento dannoso si ripercuote sulle spalle di quello onesto.

7. Spingere fino alla fork

   Bob spinge il ramo fino alla fork. Il push arriva alla sua copia del repository e la piattaforma risponde con un collegamento per aprire una richiesta pull contro Fennroot.

8. Apri la richiesta pull

   Bob apre la richiesta pull sul repository di Fennroot. Scrive un titolo e una descrizione che parlano solo del test instabile e non menzionano mai lo script di distribuzione. La correzione del test è la storia che vuole che il revisore legga. La backdoor ne è completamente esclusa.

9. Spinta per una fusione

   Con la richiesta pull aperta, Bob aggiunge un commento amichevole che invita a una rapida unione. Lo lascia sulla riga di test, in modo che l'occhio del revisore si ponga lì e non sullo script di distribuzione. Una piccola pressione sociale per approvare velocemente, prima che qualcuno legga troppo da vicino.

10. Verifica della conoscenza

    Hai appena assistito a un passaggio backdoor in una richiesta pull dietro una soluzione autentica. Chiudete perché è pericoloso.