[gdpr-discuss] Git and the Right for Rectification

[Winfried Tilanus]

On 05/25/2018 11:11 AM, Daniel Stone wrote:

Hi,

If we want to weigh the chances when there is a right to be forgotten 
court case against a Git deployment, we should make an argumentation 
chart about the possibility to change past commits and its consequences. 
That chart should include technical arguments, workflow arguments and 
arguments about traceability and integrity of the code.

Giving it a start, please improve/add/amend, I am probably saying things 
here that are bluntly incorrect!

Git is changeable because:
- it is technically possible to rebase branches
- with the right tools (which?), rebasing is feasible to do, like large 
projects like the Linux kernel show.
- the workflow needed for rebasing needs a decision by each maintainer 
of a local copy. This can be a bit of a hassle, but is doable like large 
projects like the linux kernel show.
- because each participant has to review the rebasing decision code 
integrity is maintained

Git is unchangeable because:
- changing the history is against the design of Git, all technical 
routes to do so are emergency scenarios with heavy side effects, but it 
is possible to add notes, new commits or to map e-mail addresses.
- for options like rebasing a quite disruptive additional workflow is 
needed. That workflow demands the cooperation of all developers
- Code integrity can only be guaranteed when all commits are traceable 
activities like rebasing result in untraceable code changes and endanger 
the security model behind open source software.

Winfried

ps. Beside the changeable / unchangeable discussion there is also the 
element of expectation that is relevant for the legal discussion.


> On Fri, 25 May 2018, 10:04 am Christoph Berg, <myon at debian.org 
> <mailto:myon at debian.org>> wrote:
> 
>     Re: Daniel Stone 2018-05-25
>     <CAPj87rOE9hkVkMknZoMNkp_zpKcKgXd868vULPV5vLV-MwT2wg at mail.gmail.com
>     <mailto:CAPj87rOE9hkVkMknZoMNkp_zpKcKgXd868vULPV5vLV-MwT2wg at mail.gmail.com>>
>      > > Being only a basic Git user, I need your experience here: how
>     practical
>      > > is rebasing to remove a commit message or an e-mail address from a
>      > > commit two years ago?
>      > >
>      >
>      > Technically it's completely trivial and possible to automate.
>      >
>      > Everyone pulling the repository will have to deal with the
>     result: they
>      > will need to manually reconcile the new and old state via a rebase or
>      > merge. This is something that's part of the workflow of some large
>      > repositories.
>      >
>      > The result is somewhat more painful to work with, but that's a
>     workflow and
>      > policy issue rather than a technical one ...
> 
>     This is totally impractical. Suggesting that rebasing larger git
>     repositories is feasible in practise is nonsense.
> 
> 
> It causes a workflow issue. It's not technically impossible or an 
> insurmountable limitation of the tool.
> 
> Kernel development involves quite a deal of rebasing. There are good 
> tools to handle it. I do it constantly, and am happy to advise you if 
> you're stuck or confused about how rebase works, or how to handle it on 
> the client side.
> 
> It is possible to make an argument based on the assurance given by the 
> commit history etc etc, that a linear history is necessary for proper 
> operation and rewriting it is not an option. But this is absolutely not 
> a certainty that legal authorities will agree with your incredibly blunt 
> opinion.
> 


-- 
privacy consultant e-health
+31.6.23303960
https://www.tilanus.com/