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

[Andreas Enge <andreas@enge.fr>]

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