Subject: Re: [PATCH v2 5/5] mailmap: support hashed entries in mailmaps

From: Junio C Hamano <[email-masked]>
Date: Tue, 05 Jan 2021 12:05:22 -0800

"brian m. carlson" <[email-masked]> writes:

> For example, a person may transition from one gender to another,
> changing their name, or they may have changed their name to disassociate
> themselves from an abusive family or partner.  In such a case, using the
> former name or address in any way may be undesirable and the person may
> wish to replace it as completely as possible.

I am not sure if we want to even mention the "for example" here.

These are certainly all legitimate reasons to want this feature, but
after reading the "for example", lack of a corresponding negative
statement (e.g. sometimes people also change their name or address
to hide their bad behaviour in the past that is associated with
these names) needlessly stood out and made me wonder if we need to
somehow defend the feature with "...but we do not mean to abet
people in hiding their past bad behaviour with this mechanism".  I'd
prefer us not forced to defend the mechanism if we did not have to.

> Note that it is, of course, possible to perform a lookup on all commit
> objects to determine the actual entry which matches the hashed form of
> the data.  However, this is an improvement over the status quo.

There were suggestions to use reversible encoding, IIRC, just for
obscurity.  I do not have a strong preference either way myself, but
because such an approach would give the same improvement over the
status quo, would be simpler, more performant and most importantly,
it makes it clear that this is not serious security but casual
obscurity, I'd want to be convinced why we want to use a hash here
a bit more strongly.

> +In addition to specifying a former name or email literally, it is also possible
> +to specify it in a hashed form, which consists of the string `@sha256:`,
> +followed by an all-lowercase SHA-256 hash of the entry in hexadecimal.  For
> +example, to take the example above, instead of specifying the replacement for
> +"Some Dude" as such, you could specify one of these lines:
> ...

> +SHA-1 is not accepted as a hash algorithm in mailmaps.

Is this needed to be said?  After all, we won't take @md5: or
@blake2: or anything other than @sha256: in this version (and
probably any forseeable versions).  Unless we offer a way to plug-in
algos of projects' choice, that is, and at that point, "SHA-1 is not
accepted" is a statement too strong for us to make.