{"thread":{"id":"60220","subject":"Idea: indirect authorship info","startedAt":"2023-09-11T04:23:37Z","lastAt":"2023-09-11T05:23:15Z","messageCount":2,"participants":["Yawar Amin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"481663","messageId":"CAJbYVJJUVUPNPpGAMGZKVWxYu2PiOf_16kzts009qpeLwoim+g@mail.gmail.com","threadId":"60220","inReplyTo":null,"subject":"Idea: indirect authorship info","fromName":"Yawar Amin","fromEmail":"yawar.amin@gmail.com","sentAt":"2023-09-11T04:17:21Z","receivedAt":"2023-09-11T04:23:37Z","isPatch":false,"sender":{"key":"yawar.amin@gmail.com","avatar":"https://gravatar.com/avatar/685ba1734fcdd6c21076eea14c5b629e8ebaae1dbb0107960ace97b93d76ed00?d=mp&s=160"},"body":"Hi,\n\nI have an idea about enabling management of authorship info in a git repo, to\nmake it easier to manage and potentially remove author/committer/tagger PII (in\nthe context of GDPR), without having to change any commit history/SHAs.\nApologies if this has been brought up before, but I failed to find anything\nrelevant from some quick searches:\n\n- https://lore.kernel.org/git/?q=indirect+authors\n- https://lore.kernel.org/git/?q=authors+file\n- https://lore.kernel.org/git/?q=people+file\n\nPotential use cases:\n\n- Someone requests that their names and email addresses be removed from a public\n  repo's history under GDPR Right to be Forgotten (although, based on [1], it's\n  not clear if projects could be forced to do honour RTBF or not)\n- Someone requests that their legal name change be reflected in a public repo\n\nI am interested in hearing your thoughts on this basic idea:\n\n- On committing/tagging/creating a note, the identity of the author is not saved\n  in the commit etc. object itself but in a separate file e.g. `.git/people`:\n  `d0efaf97-e18a-4197-b2c0-61c05efec75e <-> Yawar Amin <yawar.amin@gmail.com>`\n- Instead of the real identity of the author, a pointer to the `people` file\n  entry is stored e.g. `Author: d0efaf97-e18a-4197-b2c0-61c05efec75e`\n- If an entry for the person already exists in the `people` file, it is reused\n- When syncing with a remote repo, new entries in the `people` file are synced\n  along with other objects (in an append-only manner, not editing existing\n  entries)\n- Git uses the `people` file to cross-reference and fill in authorship\n  info when it renders commit etc. objects like in `git log`, `git show` etc.\n- If git can't find the authorship info in the `people` file it renders some\n  appropriate default e.g. `(Unknown)`\n\nProject owners (with write access to the hosted repo) are able to edit and push\nchanges to the `people` file. In this way they can fulfill change requests like\nthe ones I mentioned above.\n\nRegards,\n\nYawar\n\n[1] https://www.dataprotection.ie/en/individuals/know-your-rights/right-erasure-articles-17-19-gdpr\n"},{"id":"481664","messageId":"xmqq7coxjnbe.fsf@gitster.g","threadId":"60220","inReplyTo":"CAJbYVJJUVUPNPpGAMGZKVWxYu2PiOf_16kzts009qpeLwoim+g@mail.gmail.com","subject":"Re: Idea: indirect authorship info","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-09-11T05:23:01Z","receivedAt":"2023-09-11T05:23:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yawar Amin <yawar.amin@gmail.com> writes:\n\n> Apologies if this has been brought up before, but I failed to find anything\n> relevant from some quick searches:\n>\n> - https://lore.kernel.org/git/?q=indirect+authors\n> - https://lore.kernel.org/git/?q=authors+file\n> - https://lore.kernel.org/git/?q=people+file\n\nTry \"mailmap+deadname\".  You essentially reinvented these earlier\nproposals, except that they reused the existing \".mailmap\"\nmechanism, and how the key is chosen.\n\nWhile I do not think of any reason why the desire to achieve the end\ngoal of these efforts is bad, some parts of your design (and other\nproposals) need rethinking.\n\nProjects often need to know and show who did what for legal reasons.\nImagine an old commit needs to be shown to document who made the\ncontribution to the project.  An in-tree \".mailmap\" file can give\nadequate guarantee that the anatomized commit author name the commit\ncarries documents who it the really is in the \".mailmap\" file\nrecorded in the tree of that partcular commit, even if some\ncontributors who stopped contributing and asked to go back to\nanonymity have disappeared from that file.  But they may still\nappear if you did \"git log -p .mailmap\", which would meet the needs\nof these projects, but it means that you cannot be forgotten and\nhave to live with the consequences of what you did in the past.  On\nthe other hand, if there is no in-tree \".mailmap\" (or \"people\")\nfile, it brings up many questions.  It becomes unclear who will keep\ntrack of the latest version. There needs a way to guarantee that the\nentries still in the mapping file can be used to verify the claim\nthat some person did a particular commit.  Of course, as long as it\nis distributed to project participants for communication (\"hey you\nworked on this feature 6 months ago; can you answer a few\nquestions?\") and verification (\"yes, this commit was done by this\nperson who was not affiliated with company X in any way. how do you\nsubstantiate your claim that this project stole it from the\ncompany?\")  purposes, somebody will bound to make and keep copies,\nwhich means that you cannot become truly anonymous, after making\nyourself known.\n\nAs to the choice of the anonymous key used as a stand-in value for\nthe author and the committer identity, using something that is not\ndeterministic (like uuid) is not a good idea.  If the name/address\nare hashed with some algorithm that is cryptographically secure and\nis one-way, it would probably suffice both for anonymity purposes\n(as you need to \"reverse\" such a hash to get to the real author) and\nallows easy verification (if you need to \"prove\" that an anonymised\nauthor 9f5d8e44edfb7e1aa4dcf34acc3b4d643f83e1b6 recorded in the\ncommit object is an author with a known name/address, you can feed\nthat name/address to the hash function and if it hashes to the same\nvalue, that claim is as good as having the name/address directly\nrecorded in the commit object.\n\n\n"}]}