Door Anoniem: Dan is niet alleen het account gecompromiteerd maar is ook de sourcecode van de betreffende gebruikers/project niet meer betrouwbaar!
Dat valt nog wel mee. Github gebruikt git, en in git wordt elk object (opgeslagen bestand [blob], directory [tree], commit) geïdentificeerd door een hash, tree-objecten verwijzen naar die hashes (van blobs en sub-trees), commit-objecten verwijzen naar de voorgaande commit (of commits na een merge) en het root-tree-object van de repository in de staat die gecommit wordt.
Als je één bestandje wijzigt wijzigt de hash (de oude versie blijft natuurlijk ook staan in een SCM), en dus de samenstelling van de tree, de hash daarvan, en dat plant zich voort naar de root-tree (root-directory) van de repository. Het commit-object bevat die hash en de hashes van parent-commits, en de hash over elke commit is daarmee effectief een hash over de volledige repository-inhoud én de volledige historie die tot die commit heeft geleid. Wijzig één bit waar dan ook in de historie en de integriteit van de hele repository is naar zijn grootje, en dat komt snel aan het licht. Probeer je dat recht te breien door een hele geschiedenis te herschrijven dan levert dat onvermijdelijk nieuwe hashes op, en in git is dat een nieuwe branch. Iedereen die met de gewijzigde repository synchroniseert krijgt foutmeldingen, en als iemand toch een synchronisatie weet te forceren dan ziet die de histories als afzonderlijke branches naast elkaar staan, er wordt niets bestaands overschreven. Branches zijn in git geen concept dat er pas is als nadrukkelijk een branch is gecreëerd, het volgt automatisch uit de onderlinge verwijzingen tussen commits, op basis van de hashes.
en dat is in wezen een nieuwe historie waar iedereen die zijn locale kopie probeert te synchroniseren onmiddelijk fouten op krijgt. Andere hashes zijn automatisch andere branches in git.
En voor de duidelijkheid: git is een gedistribueerd systeem waarbij elke ontwikkelaar een volledige kopie van de repository heeft staan, het is dus nooit zo dat die kopie op de server de enige is.
Een aanvaller kan hierdoor (zonder rechtstreekse toegang tot het filesysteem van de server) alleen nieuwe commits toevoegen. De staat van de repository kan aan de hand van locale kopieën tot aan het moment van de aanval geverifieerd worden, en dan blijft een relatief klein aantal commits over waarvan de wijzigingen inhoudelijk moeten worden gecontroleerd. Dit is hanteerbaar.
De gebruikte hash is SHA-1. Die is voor cryptografische toepassingen aan vervanging toe, maar git zit zo in elkaar dat het niet van de cryptografische sterkte van de hash afhangt. Als een aanvaller een blob met een al aanwezige hash weet te maken en die probeert toe te voegen, dan zal een git-repository *altijd* het oude object blijven gebruiken. De aanvaller zal dus alleen meemaken dat zijn gemanipuleerde bestand door het origineel is vervangen als mensen zijn commit ophalen, het deel van de repository van voor de aanval blijft integer. En dan wordt voor de oplossers het probleem alweer gereduceerd tot het inspecteren van de laatste commits.
Als de aanvaller buiten de normale interfaces voor git om toegang tot het filesysteem van de server heeft (daar is hier geen sprake van) kan hij wel zijn blob inbrengen. Alleen zullen bestaande mirrors van de repository die nooit ophalen omdat ze al een object met die hash hebben. Als een inbraak op de server zelf wordt geconstateerd (dus niet op de voor git gebruikte interface naar de server die geen rechtstreekse toegang tot het filesysteem geeft) dan is het zaak repositories grondiger te controleren. Ik stel me voor dat je dan een hash op alle objecten met een ander algoritme dan SHA-1 maakt en op basis daarvan controleert of mirrors voor alle objecten gelijk zijn. Dat is eenvoudig te doen voor iemand die voldoende thuis is in git en *nix.
Ik heb zelf jaren geleden git als SCM gekozen omdat de basis zo sterk is. Het was op dat moment het enige SCM waarvan ik op basis van een tekst die de opslag beschreef (content-addressable storage op basis van de hashes) volledig kon beredeneren waarom er ijzersterke audit trails op basis van alleen al de manier van opslaan van objecten te maken is.
(Er is een rebase-actie die volgens critici een audit trail onbetrouwbaar maakt, maar daar ben ik het niet mee eens; het voert wat ver om die discussie te gaan voeren hier.)