Schadelijke pull-verzoeken

Wat is Schadelijke pull-verzoeken?

Een kwaadaardig pull-verzoek valt de beoordeling aan, niet de code. De verandering is klein, de beschrijving is nuttig en één bewerking zit in een bestand dat in de beschrijving nooit wordt vermeld. U dient er zelf een in: een echte probleemoplossing, plus een verborgen regel in een implementatiescript dat elke CI-variabele naar een server verzendt die u beheert. U beoordeelt het als beheerder en leest elk gewijzigd bestand in plaats van de samenvatting te vertrouwen. Vervolgens maak je de catch structureel met CODEOWNERS, vereiste beoordeling door de code-eigenaar en beperkingen op welke fork-pull-verzoeken kunnen worden uitgevoerd.

Wat je leert in Schadelijke pull-verzoeken

• Herken de rode vlag van een kwaadwillig pull-verzoek: een bewerking van een bestand dat niets te maken heeft met wat de wijziging beweert te doen, verborgen tussen legitieme diff-hunks
• Begrijp waarom het lezen van de beschrijving van het pull-verzoek niet voldoende is, en waarom een revisor de volledige diff van elk gewijzigd bestand moet openen en lezen
• Behandel bewerkingen die buiten de scope vallen om scripts te implementeren, te bouwen of te bouwen als een signaal dat een nadere, meer sceptische beoordeling rechtvaardigt
• Pas verscherping van het beoordelingsbeleid toe: CODEOWNERS voor gevoelige bestanden, vereiste goedkeuring van meer dan één revisor en limieten voor welke fork-pull-verzoeken kunnen worden uitgevoerd
• Begrijp waarom pull-aanvragen van forks buiten de vertrouwensgrens van het project vallen en extra onderzoek verdienen voordat hun code wordt vertrouwd

Schadelijke pull-verzoeken — Trainingsstappen

1. Maak het project groter

   Vandaag richt Bob zich op Fennroot, een open-source project voor ontwikkelaarstools dat pull-verzoeken van iedereen accepteert. Hij begint waar elke bijdrager zou doen: de openbare repository voor Harrow, de bouwtool van het project. Een open project is een open deur: iedereen kan het afsplitsen, wijzigen en een pull-verzoek openen. Bob is hier niet om te helpen. Hij wil dat zijn code wordt samengevoegd, en de beoordeling van een drukke beheerder is het enige dat hem in de weg staat.

2. fork en kloon

   Bob forkt de repository naar zijn eigen account en kloont de fork lokaal, zodat hij zijn wijzigingen kan doorvoeren en terug kan duwen als een pull-verzoek. Zijn plan is simpel: voeg één echt nuttige verandering toe als dekmantel en verberg een tweede, niet-gerelateerde verandering ernaast.

3. De dekking en het doel

   De dekmantel van Bob is reëel: hij repareert een werkelijk gebrekkige herkansingstest, het soort kleine bijdrage dat een project verwelkomt. Die verandering is eerlijk en nuttig, en dat is het hele punt. Het zorgt ervoor dat het pull-verzoek er routinematig uitziet. Zijn werkelijke doelwit is een geheel ander bestand. Hij opent het implementatiescript, dat niets met een test te maken heeft, en leest het schoon.

4. Plant de achterdeur

   Bob voegt een enkele regel toe aan het implementatiescript. Het lijkt op een onschuldig stukje build-telemetrie, maar het verzendt elke omgevingsvariabele naar een server die hij beheert. Het implementatiescript wordt uitgevoerd in het CI van het project, waar deze variabelen implementatiesleutels en registertokens bevatten. Eén regel in een bestand vermeldt het pull-verzoek nooit. Dat is de hele aanval.

5. In het volle zicht begraven

   De regel leest als iets dat een bouwingenieur zou kunnen toevoegen, en bevindt zich tussen de gewone implementatiestappen. Niets schreeuwt om een ​​aanval, en dat is precies waarom het een snelle vlucht overleeft.

6. Voer beide wijzigingen door

   Bob staget en voert beide bewerkingen samen uit: de echte testfix en de implementatiescriptregel, in één commit. Samen gebundeld, komt de kwaadaardige verandering binnen op de rug van de eerlijke.

7. Duw naar de fork

   Bob duwt de branch omhoog naar zijn fork. De push gaat naar zijn eigen kopie van de repository en het platform antwoordt met een link om een ​​pull-verzoek tegen Fennroot te openen.

8. Open het pull-verzoek

   Bob opent het pull-verzoek in de repository van Fennroot. Hij schrijft een titel en beschrijving die alleen over de zwakke test gaan, en nooit over het implementatiescript. De testfix is ​​het verhaal dat hij wil dat de recensent leest. De achterdeur wordt er geheel buiten gelaten.

9. Een duwtje in de rug voor een fusie

   Terwijl het pull-verzoek geopend is, voegt Bob een vriendelijke opmerking toe die aanzet tot een snelle samenvoeging. Hij laat het op de testregel liggen, zodat de blik van de recensent daar terechtkomt en niet op het implementatiescript. Een beetje sociale druk om snel goed te keuren, voordat iemand te goed leest.

10. Kennis check

    Je hebt zojuist een achterdeur zien binnenrijden in een pull-verzoek achter een echte oplossing. Ontdek waarom het gevaarlijk is.