Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jan 15, 2021, 00:29 UTC
Message-ID: <YADh2DHDrdAs6Jbj@camp.crustytoothpaste.net>
In-Reply-To: <YADZSsVqyGnArF0n@google.com>

On 2021-01-14 at 23:52:42, Emily Shaffer wrote:

Show 8 quoted lines

> Firstly: this design comes from a conversation amongst a pretty small (4
> people? 6 people?) group at the virtual inclusion summit some months
> ago. At that time, we discussed the ease of brute-force decoding the
> one-way-hashed mailmap and decided that, as long as Git didn't ship a
> tool to do this for you for free, it was better than the current
> solution for avoiding deadnames (i.e. "sorry"). I'm disappointed to see
> the larger list feel otherwise, but not terribly surprised, since the
> list contains more people than the group who came up with the design.

Yes, thank you for sharing this helpful context. I will add that there were a couple folks in that conversation who had mentioned that the hashed mailmap was an idea they'd thought of (of which I was one) and I did commit to bringing it to the list.

> Secondly: it seems like a restatement of the goals of this patch would
> help guide a discussion of designs; I would be so pleased to see a
> cleaner solution than any that's been proposed so far, because I agree
> that this feature is not perfect. So please append what I have missed:

I completely agree. If there are better ideas, I'd be delighted to hear them, even if the proposer isn't interested in implementing them.

Show 20 quoted lines

> Axiom: The current Git solution for avoiding deadnaming is insufficient.
> Axiom: We want to improve Git's solution for avoiding deadnaming.
> (That is, I don't think either of these statements are or should be up
> for discussion.)
> 
> Goal: Projects which are contributed to by trans individuals who
> transition during their contribution period should provide a good,
> supportive experience, which does not deadname the individual.
> Goal: Git's performance should not suffer unduly from any change unless
> necessary.
> Goal: Project maintainers should have an understanding of the threat
> model (e.g. automated tools scraping for names, malicious individuals
> with time on their hands and experience with the project, etc)
> Goal: Audit trails required by e.g. SOB lines should exist for the
> project maintainer, if necessary
> Goal: Mailmap, in general, should work better than it does now
> Goal: An imperfect solution should not disallow a more perfect solution
> later down the road
> Bonus goal: For the sake of Git project contributors, it would be nice
> to avoid a troll storm on list.

I agree with all of these.

Considering the last point, part of the reason I volunteered to present this idea to the list was that I expected some trolling and general poor behavior (hence my reminder about the CoC) and I'm comfortable with taking the flak here. I am (and I'm sure everyone else on the list is) delighted that we didn't see that.

Show 9 quoted lines

> Thirdly: As is stated elsewhere, I think this topic is falling victim to
> perfect vs. good. Git is gaining increasing notoriety in circles I can
> see about the ultimately crappy experience for people who change their
> names and don't want to hear the old names (and don't want to know the
> old names). In my opinion, literally anything we could do to improve
> this experience would be better than doing nothing. So I feel sad to see
> the topic dropped because of pushback, especially when that pushback is
> "I'd like to write a tool to reverse this thing, because <vague reasons>
> - and I don't mean that tool maliciously so that should be OK."

If folks feel that my series is at least better than the status quo and do want it to be picked up, I can do the reroll I was planning on doing. It sounds like there may be some support for that.

I think that does implicitly mean, though, that we're agreeing that maybe adding a tool to reverse hashes isn't something we want to adopt in Git, at least until we have a better or different solution in place. While I agree there could be some legitimate uses for it, we do have to be cognizant of the potential for misuse and abuse (as when writing any software).

-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US