"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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.
