Manually changing email addresses
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.
In the News References
I wanted some place to reference some case studies about why social engineering attacks against users for identity theft is a serious problem. This seemed like the most appropriate location. This applies not only to changing email addresses but also changing passwords. We must be careful.
Actually doing it
Log into the Savannah web interface. "Become Superuser". Go to the site "Main page". "Browse Users List". Search for the user. Visit the username link page. Change the password using the provided web form.