On March 12, 2022 7:04 PM, Junio C Hamano wrote: >To: Sean Allred <allred.sean@xxxxxxxxx> >Cc: git@xxxxxxxxxxxxxxx; sallred@xxxxxxxx; grmason@xxxxxxxx; >sconrad@xxxxxxxx >Subject: Re: Dealing with corporate email recycling > >Sean Allred <allred.sean@xxxxxxxxx> writes: > >> As a baseline, we know the following statements are true: >> >> 1. A person's preferred name can change at any time. >> 2. A person's preferred email can change at any time. >> 3. Neither of these pieces of information are necessarily >> identifying in a given codebase. > >Another thing we know is > > 4. People know that old e-mail addresses stay in archives and > address books of people, and find it wise to avoid reusing an > address somebody else (especially well-known ones) has been > using, so that they do not get e-mails from total strangers > and having to tell them that the intended recipient does not > read the mailbox anymore. > >> 1. Do nothing. Leave it to the developer to determine the correct >> contact information without assistance. >> >> This doesn't really resolve the confusion, but it is technically >> an option. >> >> 2. Use gitmailmap(5) functionality to resolve historical emails to >> primary emails. >> >> Sadly this doesn't actually solve the email recycling problem. >> Since one email could be used by multiple developers, there's no >> way (that I can see) to use a single mailmap file to resolve one >> of these emails to a single person. > > >GNU arch (tla) had an interesting idea around this area and used combination of >time and e-mail address to identify a person. >one@corp--$date referred to the person who had control of the address on the >specified date, where $date can be abbreviated to >2022 or 202201 to mean 20220101. > >The mailmap allows "Name e-mail" or "e-mail" to be mapped to canonical "Name >e-mail", but we should be able to coax "valid time range" information encoded in >each entry of the .mailmap format, i.e. "if you see 'Name e-mail' between time X >and Y, map that to...". Is there anything we could do around the new signature infrastructure relating to this? I am NOT a fan of SSH keys without passphrases, but what if we could use the coaxing above and map to SSH expiring keys then stitch in signatures (a.k.a. sign the commits) to correspond to the users in the given timeframe - then destroy the private keys to prevent further signing. After that the Name/email becomes somewhat irrelevant from an integrity standpoint.
