Manually changing email addresses
Log into the Savannah web interface. "Become Superuser". Go to /user/user_name. "Edit User". Change the email using the provided form.
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.
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.