Git und Non Repudation

Dieser Aufsatz bezieht sich wirklich auf DVCS im Allgemeinen, nicht nur auf Git per se. Aber wir werden die Aufmerksamkeit auf Git konzentrieren, weil es bis heute die beliebteste DVCS ist.

Nicht zurückweisend.

Mit einem traditionellen, zentralisierten Tool zur Versionskontrolle sind solche Datensätze aus der Commit-Historie leicht verfügbar. Jede Zusage an das System durchläuft einen Autorisierungsmechanismus, um sicherzustellen, dass die Person, die diese Änderung vorgenommen hat, zum Hochladen autorisiert ist. Diese Datensätze sind für das Unternehmen von entscheidender Bedeutung, um sicherzustellen, dass genaue Datensätze gespeichert 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 — die ich als “Push Records” bezeichnen werde. Commits in git werden nicht authentifiziert, da sie lokal erfolgen, wobei lokale, nicht verifizierte Metadaten zur Historie hinzugefügt werden. Der Uploadschritt, aka git push

Mit Die Apache Software Foundation.

Warum ist das wichtig? Nun, zunächst lassen Sie mich ein häufiges Missverständnis über die Notwendigkeit von Beitragenden Lizenzvereinbarungen (ICLAs) für Apache-Committers ansprechen. Viele Menschen scheinen nicht zu verstehen, dass, soweit ein Committer einzelne Werke der Autorenschaft, gibt es 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, auf jede Codezeile in einem Release zurückzuverfolgen, der einzelne Committer, der dafür verantwortlich ist, diesen Code an das Git-Repository der ASF zu übertragen. Dies ist von entscheidender Bedeutung für die Bestimmung der Herkunft eines Drittbeitrags mit Git, da es für einen solchen Mitwirkenden leider möglich ist, sich von seinem Beitrag zu einem Git-Projekt wegen der verteilten Natur von DVCS-Commit-Logs zu entfernen. Die verantwortliche Partei wird nach Angaben der ICLA dann der Committer, der den Code gepusht hat.

Frühe und angemessene Minderungsstrategien drehen sich um die Beseitigung des aufgegebenen Beitrags, aber der Schaden am Projekt ist möglicherweise bereits entstanden. Und ohne die Push-Aufzeichnungen hätten wir buchstäblich keinen autoritativen Prozess, um zu bestimmen, wie dieser Code tatsächlich in unser Repo gelangt ist, außer durch alternative Aufzeichnungen in Problem-Trackern oder auf der Liste Kommunikation. Sich allein auf Merge-Commit-Logs zu verlassen, um die Herkunft zu bestimmen, ist aus Sicherheitsgründen nicht sehr befriedigend, da es eine starre Einhaltung eines bestimmten Workflowtyps erfordert, den wir nicht diktieren möchten.

Ohne solche Dinge müssten wir zumindest die PGP-Unterzeichnung der Verpflichtung jedes Mitwirkenden vorschreiben, was für viele Projekte belastend ist. Push-Datensätze bieten einen transparenten Prozess, der sich nicht auf den Workflow eines Projekts auswirkt, außer um sicherzustellen, dass das Git-Repository der ASF das echte Master-Repository ist.

$Datum: 2023-01-19 22:58:40 +0000 (Do, 19 Jan 2023) $