Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[MSavoritias <email@msavoritias.me>]

On 3/18/24 15:35, Andreas Enge wrote:

> Hello all,
>
> Am Mon, Mar 18, 2024 at 12:26:18PM +0100 schrieb Simon Tournier:
>> Therefore, it would be more constructive if you come with a
>> proof-of-concept allowing “history rewrite” and strong “software
>> identification” property
> the one thing I can think of, and which would allow time travel to coexist
> with history rewriting, is an additional layer of metainformation.
>
> First of all, when rewriting history, all commits from the bifurcation
> to an alternate universe must be signed again by the person doing the
> "time split"; so there is a loss of information there.
>
> Second, we need to create a table that associates every old, lost commit
> hash to the corresponding new commit hash; this should also be signed by
> the person rewriting history.
>
> Of course this will have to be continued to the future: If Guix has n
> commits and m history rewrites, then the m-th rewrite may have to create
> a table of n entries that link commit hashes of the m-th rewrite to those
> of the (m-1)-th rewrite. Total memory would become m*n entries.
>
> When doing time travel to a commit hash, one would need to check whether
> it is available in the current, m-th history rewrite; if not, one would
> need to look for it in the (m-1)-th rewrite and map it to a commit hash
> in the m-th rewrite; if not, one would have to look for it in the (m-2)-th
> rewrite and map it to a hash in the (m-1)-th rewrite, and then check
> whether or not it has been overwritten in the m-th rewrite. The total
> time complexity would be m look-ups in tables of size n each.
>
>
> It is a lot of effort; and probably for little gain, since we cannot
> eradicate each and every fork of the Guix git repo. The old data will
> still be available at SWH, and probably at random forks on lots of random
> forges all over the world. As Simon, I think that history, fundamentally,
> cannot be rewritten: What has happened in the past, has happened in the
> past. If you have done some public activity as the person known as X, and
> then change your name to Y, you cannot prevent your past activity to be
> known under identity X. Also, the time split would have to be publicly
> documented somehow; if we add as rationale for a history rewrite "person X
> is now known as Y", not much is gained compared to just keeping the old
> commits. Not documenting the rationales for history rewrites would not help
> to instill trust in the codebase, and probably not solve the problem either,
> since it is quite likely that the request by person X to now be addressed
> as Y will have been made on the mailing list or some other public forum.
>
> So my impression is that the .mailmap approach in the Guix project is a
> good compromise between acknowledging the wish of people to be known under
> identity Y, and what can reasonably be achieved to hide identity X.
>
> Well, there are things people can do individually:
> 1) Use a pseudonym P from the start instead of X (which is admitted in
>     the Guix community, just look at a few of the names: there are pseudo-
>     nyms with clearly made-up first and last names, there are very obvious
>     one-word pseudonyms, and maybe some of the names that look like real
>     names are not from the persons' passports, who would know).
> 2) This does not help, of course, if you are already known as X and want
>     to be known as Y. Then either you can somehow make the change publicly,
>     and transfer your reputation and also the information that you used
>     to be known as X, or disappear as X and reappear as a new person Y
>     and lose X's reputation. Doing both is impossible, I would say.
>
> Andreas
>
Rewriting history is the wrong question imo. I dont think a request to 
change all of the history of Guix will be accepted anyway.

A much easier thing to do is to change the approach in the future. And 
let all the past history untouched.


MSavoritias