Re: GDPR compliance best practices?

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jun 8, 2018, 22:42 UTC
Message-ID: <20180608224246.GC42503@aiede.svl.corp.google.com>
In-Reply-To: <20180417191549.GA1199@helen.PLASMA.Xg8.DE>

Hi,

Peter Backes wrote:

> I'd like to ask whether anyone has best practices for achieving GDPR
> compliance for git repos? The GDPR will come into effect in the EU next
> month.

This is a reasonable question to ask other Git users on this list to share ideas, so thanks for asking it.

> In particular, how do you cope with the "Right to erasure" concerning
> entries in the history of your git repos?

Later in the thread you discussed some changes you would like to make to Git or in front of Git to ensure that people can erase their authorship information from a repository after the fact in a non-disruptive way.

I have no opinion about how that relates to GDPR requirements. I tend to expect any legal advice a person gets to be situation-specific; it's much harder to get legal advice that is useful to share.

Separate from that legal context, though, I think it's an interesting feature request. I don't think it goes far enough: I would like a way to erase arbitrary information from the history in a repository. For example, if I accidentally check in an encryption key in my repository as content or a commit message, I would like a way to remove it, assuming that others who fetch from the same repo are willing to cooperate with me, of course (i.e. in place of the object, the server would store a placeholder and an _advisory_ token allowing clients to know (1) that this object was deleted, (2) what object to use instead, and (3) an explanatory note about why the deletion occured; clients could make whatever use of this information they choose).

I've seen some discussion on this subject at https://www.mercurial-scm.org/pipermail/mercurial/2008-March/017802.html long ago and have some ideas of my own, but nothing concrete yet. Anyway, I thought it might be useful to get people's minds working on it.

Thanks, Jonathan