Policy
Bradley Kuhn says:
I suggest that we follow this procedure:
* Send a message to the address on file, and see if it bounces.
If it doesn't bounce, then we must ask the original user
why, and decide what to do on a case by case basis. We
should be EXTREMELY reluctant - if not outright REFUSE - to
change an email address if the one on file does not bounce.
* If the mail does bounce, we should ask the user if they can
produce any evidence that they once had that email address.
The best evidence would be a GPG-signed message that is
signed with a key that has both their old and new email
address on it, and that the GPG key be available from a
well-known public keyserver. While this could be forged, it
would be substantial work to do so and could easily get
discovered.
(Note, this is why I say the key much be on a public
keyserver. Even if they forge the key to refer to email
addresses they don't control (i.e., generate a key that
includes bogus info), putting on a public key server could
likely flag the real owner of the email address.)
* If they cannot use the GPG solution, I suppose we should
accept any plausible explanation for why their old email
address is bouncing (e.g., changed ISP). If someone truly
wants to social engineer their way into commit access on a
project, they can likely do it. We can't beat it; we can
just make it some effort to succeed in such social
engineering.
Actually doing it (running this on internal.in.sv.gnu.org is preferred):
mysql savane
update user set email="new e-mail" where user_name = "username" and user_id=uid;
Double checking the user_name and user_id is good for security :)