Git und Non Repudiation, Revisited
Joe SchaeferDieser Aufsatz bezieht sich wirklich auf DVCS im Allgemeinen, nicht nur git per se. Aber wir werden die Aufmerksamkeit auf Git lenken, weil es das beliebteste DVCS bis heute bleibt.
Mit einem traditionellen, zentralisierten Versionskontrolltool sind solche Datensätze leicht aus der Commit-Historie verfügbar. Jeder Commit an das System durchläuft einen Autorisierungsmechanismus, um sicherzustellen, dass die Person, die diese Änderung vorgenommen hat, berechtigt ist, sie hochzuladen. Diese Aufzeichnungen sind für das Unternehmen von entscheidender Bedeutung, um sicherzustellen, dass genaue Aufzeichnungen geführt werden, die angeben, wer für das Hochladen jeder Codezeile in die betreffende Software verantwortlich ist.
mit git oder verteilter Versionskontrolle im Allgemeinen, Es gibt einen klaren Unterschied zwischen der “Commit”-Geschichte und der “Upload”-Geschichte — Ich werde sie als “Push Records” bezeichnen. Commits in git werden nicht authentifiziert, da sie lokal erfolgen und lokale, nicht verifizierte Metadaten zur Historie hinzugefügt werden. Der Upload-Schritt, aka Git-Push
Mit Die Apache Software Foundation.
Warum ist das wichtig? Nun, für Anfänger, lassen Sie mich ein häufiges Missverständnis über die Notwendigkeit von Contributor License Agreements (ICLAs) für Apache-Committers ansprechen. Viele Menschen scheinen nicht zu verstehen, dass es in Bezug auf die einzelnen Werke der Autorschaft eines Committer keinen Unterschied zwischen der anwendbaren Sprache in der ICLA und die Apache-Lizenz 2.0.
Was Push-Datensätze dann bieten, ist eine Möglichkeit, zu jeder Codezeile in einem Release zurückzuverfolgen, der einzelne Committer, der dafür verantwortlich ist, diesen Code an das Git-Repository des ASF zu übertragen. Dies ist von entscheidender Bedeutung, um die Herkunft eines Drittbeitrags mit git zu bestimmen, da es für einen solchen Mitwirkenden leider möglich ist, wegen der verteilten Natur von DVCS-Commit-Logs von seinem Beitrag zu einem Git-Projekt “abzugehen”. Die verantwortliche Partei wird dann laut ICLA der Committer, der den Code gepusht hat.
Frühe und angemessene Minderungsstrategien drehen sich alle um das Entfernen des aufgegebenen Beitrags, aber der Schaden am Projekt ist möglicherweise bereits geschehen. Und ohne die Push-Datensätze hätten wir buchstäblich keinen maßgeblichen Prozess, um zu bestimmen, wie dieser Code tatsächlich in unser Repository gelangt ist, außer durch alternative Datensätze in Problem-Trackern oder in der Kommunikation auf der Liste zu trawlingeln. Sich allein auf Merge-Commit-Logs zu verlassen, um die Herkunft zu bestimmen, ist aus Sicherheitsgründen nicht sehr zufriedenstellend, da es eine starre Einhaltung einer bestimmten Art von Workflow erfordert, die wir nicht diktieren möchten.
Ohne solche Dinge müssten wir zumindest die PGP-Unterzeichnung des Engagements jedes Mitwirkenden vorschreiben, was für viele Projekte schwierig ist. Push-Datensätze bieten einen transparenten Prozess, der sich nicht auf den Workflow eines Projekts auswirkt, außer sicherzustellen, dass das Git-Repository des ASF das wahre Master-Repository ist.
2025-Update
Git unterstützt nativ SSH-SK-ED25519@openssh.com
Die unnötige Aufblähung und Komplexität einer vollständigen PGP-Infrastruktur ist nicht mehr relevant, um die oben diskutierten Nichtrückweisungsprobleme im gesamten Unternehmen oder auf Projektebene zu lösen. Und die schöne GitHub-Integration erleichtert diesen Aufwand vollständig.