Issue 716: Better error message on invalid email address
Status:  Duplicate
Merged:  issue 909
Owner: ----
Closed:  May 2011
Cc:
Reported by tomtheen...@gmail.com, Sep 4, 2010
Affected Version: 2.1.5

What steps will reproduce the problem?
1. Accidentally set your email address in your .gitconfig first.last@example.com, when you are registered as First.Last@example.com on gerrit.
2. Attempt to push a change for which you should have access.
3. Permission denied error from gerrit and the push fails.

Please provide any additional information below.

The above example is one of many permissions errors that can occur and are simple to fix, but very hard to debug because gerrit does not indicate what permission failed. It also doesn't appear to be logged in any of the logs.

It would be quite helpful to have gerrit specify exactly what permission caused the failure either as part of the push or at least in the logs.
Sep 6, 2010
Project Member #1 fredrik....@sonyericsson.com
It is generally considered bad security practice for systems to give away information about users in the system. This could be interpreted as a very anonymous and hostile kind of service in a intranet environment, however for a public service this kind of silence is probably well needed.

I advice strict caution when giving away more user data than the connection in question has given, although I can understand the kind of frustration you have seen.

Maybe it's better for the login to not be case sensitive? I never seem to remember if the smtp protocol specifies case sensitivity or not in addresses. I believe it's necessary to follow the smtp standard in this case however.
Sep 6, 2010
#2 sop@google.com
According to RFC 2821 (which is what governs most SMTP transactions
these days), section 2.4:
 
  Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
  and extension name keywords) are not case sensitive, with the sole
  exception in this specification of a mailbox local-part
 
So "first.last@" and "First.Last@" are two different addresses.
 
However "first.last@EXAMPLE.com" and "first.last@example.com" are
the same address, as its the domain and not the local-part that is
case insensitive.
 
For simplicity reasons Gerrit just enforces that the entire email
address is case sensitive and must match exactly.
 
 
The way I read this issue is, we should be better in our error
reporting.  Instead of an obtuse error during push we should be a
bit more forgiving to our end-user:
 
  $ git push ... HEAD:refs/for/master
  ...
  remote:
  remote: ERROR - An email address does not match ones on file for you.
  remote:
  remote: INVAILD EMAIL ADDRESS: First.Last@example.com
  remote:   (first found in commit c0ffee42...)
  remote:
  remote:
  remote: If this address belongs to you, it can be registered by visiting
  remote: http://gerrit.example.com/#settings,contact
  remote:
  remote: To change the address in Git, please review the documentation
  remote: at http://gerrit.example.com/Documentation/help-me-please.html
  remote:
  ...
 
There isn't a need to give the user more information than we 
already are handing out.  We just give a really crappy error message
with no advice on how to proceed.  For many users, this is their
first Git and Gerrit experience.  We should at least point them to
documentation that helps them recover and continue.

Summary: Better error message on invalid email address
Status: Accepted
Sep 6, 2010
#4 tomtheen...@gmail.com
Shawn, you've interpreted my comments exactly right. The issue isn't the particular problem of email address capitalization, but the general issue of error messages lacking specificity. If specific error messages to the user are deemed a security issue, then at least logging the specific error in the logs would help the administrator track down the issue.
May 19, 2011
Project Member #5 nas...@grainawi.org
We now have docs explaining the error messages. Next step is to link to the docs or include shorter versions in the errors themselves.
Cc: edwin.ke...@gmail.com
May 20, 2011
#6 sop@google.com
(No comment was entered for this change.)
Status: Duplicate
Mergedinto: 909