RE: Wildcards in mailmap to hide transgender people's deadnames

>On Wed, Sep 14 2022, Florine W. Dekker wrote:
>
>> On 14/09/2022 09:40, René Scharfe wrote:
>>> Am 13.09.22 um 23:53 schrieb Florine W. Dekker:
>>>> Now, John can now add the following line to their mailmap config:
>>>> `John Doe <john.doe@example.com> <\*.doe@example.com>`, which does
>>>> not reveal their old name.
>>> That would falsely attribute the work of possible future developers
>>> ann.doe@example.com and bob.doe@example.com to John as well.
>
>First, I'm very happy to see that someone has picked up the thread on this again.
>
>> Good point. I assumed such false positives would be unlikely because I
>> was considering very-small-scale projects, but I agree that using
>> wildcards is not at all feasible for larger projects.
>
>Yes, please, making the mapping fuzzy in any way is really going against the core
>design of the mailmap mechanism, it should be unambiguous,
>*also* for commits going forward.
>
>>> Supporting hashed entries would allow for a more targeted obfuscation.
>>> That was discussed a while ago:
>>> https://lore.kernel.org/git/20210103211849.2691287-1-sandals@crustyto
>>> othpaste.net/
>>
>> That was an interesting read. I agree with Ævar in that thread in that
>> I think URL encoding is sufficient. I think it meets Brian's use case
>> of never having to see the old name again, and my use case of
>> obfuscating it from accidental discovery by friendly collaborators.
>
>The question that was left open in my mind after that previous discussion was
>weather people who wanted the "deadname" feature would find this acceptable,
>I don't think we got any explicit ACK/NACK on that (but I may be misrecalling, and
>didn't go back & re-read the whole thing).
>
>I'm happy that there's at least one ACK to it here in the form of your reply, and
>hopefully that represents what a wider audience would prefer.
>
>> While a hash certainly gives a stronger sense of security, I think
>> it's a false sense of security, because, as you note below, recovering
>> old email addresses from the tree is not much more trivial than
>> reversing the encoding. And either way, a sha256 hash can easily be
>> inverted in a few days(?) using a dictionary attack with email
>> addresses from data breaches.
>
>It's going to be "milliseconds", not "days". Brute-forcing a SHA-256 to find an
>unknown E-Mail address might take longer, but by definition for a .mailmap entry
>you already have both sides.
>
>So "brute-forcing" is just a matter of hashing authors & E-Mails in our history, and
>seeing if they correspond to .mailmap entries.
>
>> As someone who has changed her name, I would be content with using a
>> simple URL encoding.
>
>I'd be happy to have that as a feature, in particular because (as I pointed out in the
>previous discussion) it has a large use-case outside of this .mailmap topic, namely
>wanting to map e.g. mis-encoded author names in past commits to the right
>encoding (which I've personally had some use-cases for).
>
>There might be other "bonus" use-cases I've missed. E.g. is ">" or "<"
>allowed in obscure E-Mail addresses (maybe within quotes?), our current parser
>would barf on it, but being able to URI-encode it would work around that. I don't
>know offhand to what extent there's an overlap with various RFC-pedantic E-Mail
>addresses one could come up with, and what we'd accept in commit objects with
>"fsck".
>
>In any case, I think that an implementation of this & patch to
>gitmailmap(5) should explain this sort of feature in those terms. If some people
>then find it useful to encode things in the ASCII-space for some reason (e.g. the
>social "deadname" reason) that would also be useful.
>
>But in terms the docs I don't think it should be documented in that way. Git just
>needs to provide the feature, we don't need to dictate how & why someone
>might use it.
>
>>> [...]
>>>     $ git log --format='%ae %aE' |
>>>       awk '$1 != $2 && !a[$0] {a[$0] = 1; print}' |
>>>       grep -F l.s.r@web.de
>>>     rene.scharfe@lsrfire.ath.cx l.s.r@web.de
>>>
>>> The same can be done with names (%an/%aN).
>>
>> You're absolutely right. With "advanced tools" I was referring to
>> anything more advanced than a plain `git log` ;-)
>
>The thing that still makes me a bit nervous on this topic is that we need to make it
>really clear that we're *not* providing some promise of obscuring these values
>going forward, but just providing a feature that some people might rely on as a
>combined social mechanism, and with the assumption that the defaults of the "git
>log" view are unlikely to change.
>
>I.e. I think a "deadname" use-case of this would probably:
>
>* Have some comment at the top of .mailmap about why some values are
>  over-encoded (or perhaps it would be obvious to everyone working on
>  that repo why someone was encoding the "plain ASCII" A-Za-z0-9 space).
>
>* Use the default "git log" view, where we happen to map these (given
>  the right options, config etc.)
>
>But should not:
>
>* Assume that other tools such as "fsck", "check-mailmap" or even "log"
>  won't have future features that make de-obscuring these values easier,
>  or something that's part of a normal workflow.
>
>  E.g. I've wanted a "fsck for mailmap" for a while, i.e. to scan the
>  file, parse our history, and see which entries are redundant or even
>  potentially missing (based on e.g. names matching, but having
>  different E-Mail addresses).
>
>  It would be hard not to de-obscure URI encoded values for some
>  features like that, e.g. if "log" adds the ability to say "this name X
>  was mapped from Y".
>
>* In general pretend that the mailmap is anything but a *public* and
>  easily readable mapping. It's inherent in the feature that the
>  consumer of it will know that X used to be Y.
>
>The last thing we want is to create some feature that effectively ends up being
>some self-doxxing (or self-"de-deadnaming"?) mechanism, because we've left a
>gap between user expectations and what we can realistically provide.