On July 3, 2020 2:23 AM, demerphq wrote: > On Thu, 2 Jul 2020 at 18:42, Randall S. Becker <rsbecker@xxxxxxxxxxxxx> > wrote: > > I am not speaking for the Git Foundation here, nor am I a lawyer; However, > to use some practices from some of my customers who have this concern, > the team members are directed to use tokenized names and email addresses > that can be resolved by their security teams during an audit. Obviously the > team members recognize the tokens so they know who is making what > change. This means that externally, any names/emails that might get pushed > upstream are non-identifying. > > I think this is a really good point. I think git could make itself much more > GDPR friendly by having some support for this type of idea built in. > > Not sure how it could work, maybe some kind of object that can be deleted > after the fact which maps an identifier used for the author with name and > email. If that name and email change the object can be updated, and if there > is a need to "forget" the author, the object can be deleted. The object would > not be shared on clone, so it would stay private to the repo that held it. > > I guess you can argue that this isnt git's problem. But at a corporate level, it > will be seen as git's fault regardless if it cause a big disruption. It could/would > also be a reason that european companies might decide not to use git. How you choose to identify yourself to git is entirely arbitrary. There are SSO solutions used by GitHub that have the personal information stripped out. I contend that this is not git's problem because anyone can use anything to self-identify. Git does not care. Policies can be implemented (commit-hooks) to automatically tokenize but that's up to what the corporation wants to do. In fact, git is less subject to GDPR issues than other VCS systems, which uses the logon credentials that are personal-identifying in many locations and could represent a security vulnerability. So while a corporation can choose to find fault with git, the fault is in their own credential management policies. It might be worth some documentation to explain this.
