guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: MSavoritias
Subject: Re: rewriting history; Was: Concerns/questions around Software Heritage Archive
Date: Mon, 18 Mar 2024 16:03:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]