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

[Daniel Littlewood]

Hi everyone,

I think the discussion so far splits into "should something be done"
and "what can be done". The "should something be done" is easier to
address, I think, so I'll deal with it first. I particularly have
Attila's reply in mind.

> let's put aside the trans aspect of this question for a moment,
> is it reasonable for me to demand from somebody else to change their memory 
> of my past actions?
> if so, then where is the line? what's the principle here? and what are its 
> implications?
> i sure see some actors out there who can hardly wait to start erasing certain 
> records at the barrel of the law

I do not doubt that there are bad actors who might misuse the ability
to rewrite history generally. However, this only allows us to dismiss
the technical challenge if there is *no* legitimate use case for
rewriting history, ever, in any circumstance. So rather than removing
the trans aspect of the question to consider every possible use case
(good or bad) of rewriting history, it seems like we only need to come
up with a single case that's sufficient to justify altering someone's
identity, for it to be worth considering if the technical restriction
could be avoided. But then the answer is obvious: Someone might just
sign their commits wrong for whatever reason. Is it valuable for a
user or for guix generally to preserve metadata in the case where a
commit is signed incorrectly? Obviously not. So whether you are
sympathetic to the deadnaming issue or not (personally I am) it seems
like we can dismiss the question "should we do something about it".

As for what could be done, if I understand the discussion so far (I'm
not an expert in guix internals) the only reason we care about
identity is that it's part of git commits. If that's really all it is,
then I wonder if the following scheme would resolve the issue?

* Start with git repo A, signed with an identity now considered
incorrect for some reason.
* Rewrite history to replace the old signer with the new signer. Make
no other changes to the content of any commit. This produces
repository A'.
* Repository A and A' should have identical numbers of commits, and
identical content of the code at each commit. Therefore we can set up
a one-to-one mapping from the commits of A to the commits of A'.
* Store this mapping of "deprecated commits" (pairs of commit hashes,
pointing from the deprecated commit to its corrected version) in a
database somewhere, and discard repository A.
* Whenever we attempt to look up a commit, if the lookup fails, try to
look in the deprecated commits database. Perhaps emit a warning that
the commit hash is deprecated and should be updated.

Note that point 3 (that the content is identical in each commit) could
be violated. e.g. perhaps there is a "CONTRIBUTORS" file which also
needs to be scrubbed. This would present an algorithmic difficulty (if
we actually tried to verify the code is unchanged) but if a trusted
maintainer of the project is authorising the deprecation, then we
don't actually need to know that the code is unchanged.

Note also that this deprecation mechanism would fix the problem for
simple forks too. e.g. in the case referenced, if someone packaged a
fork of the deadnamed repo, then looking up a commit that was created
pre-fork and included the old identity, then looking up that commit
could notify the user that the repo should be updated.

Does this sound at all sane?

Best wishes,
Dan

On Mon, Mar 18, 2024 at 11:26 AM Simon Tournier
<zimon.toutoune@gmail.com> wrote:
>
> Hi,
>
> On lun., 18 mars 2024 at 12:10, MSavoritias <email@msavoritias.me> wrote:
>
> > The right of a trans person to ask a project to not advertise their
> > deadname was never in question.
> >
> > Guix is a place that supports trans people and anybody else that wants
> > to change their name.
>
> There is a difference between “advertise” and “part of the history”.
>
> Do not take me wrong.  The right to be forgotten is one topic.  However,
> as many people are saying: it is not an easy question.  There is legal
> questions, technical questions, social questions, etc.
>
> For what it is worth, Guix is built around the concept of immutability.
> This is a core concept and deep in Guix internals.
>
> Therefore, it would be more constructive if you come with a
> proof-of-concept allowing “history rewrite” and strong “software
> identification” property [1].  Else, the discussion is leading nowhere,
> IMHO.
>
> 1: https://guix.gnu.org/en/blog/2024/identifying-software/
>
> Cheers,
> simon
>