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@xxxxxxxxxxx> <\*.doe@xxxxxxxxxxx>`, which does
not reveal their old name.
That would falsely attribute the work of possible future developers
ann.doe@xxxxxxxxxxx and bob.doe@xxxxxxxxxxx to John as well.
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.
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@xxxxxxxxxxxxxxxxxxxx/
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. 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. As someone
who has changed her name, I would be content with using a simple URL
encoding.
Someone could always spend more effort to uncover the name using more
advanced tools, but the point of this feature is to prevent
accidental discovery of the name in cases where completely hiding the
name is not feasible.
Extracting old email addresses from a repository is easy by comparing
authors' email addresses without and with mailmap applied, no advanced
tools required. Here's mine from Git's own repo:
$ git log --format='%ae %aE' |
awk '$1 != $2 && !a[$0] {a[$0] = 1; print}' |
grep -F l.s.r@xxxxxx
rene.scharfe@xxxxxxxxxxxxxx l.s.r@xxxxxx
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` ;-)
- Florine
