Over-zealous username validation in UI

[mrichar1]

• Gitea version (or commit ref): 1.4.1
• Git version: 1.8.3.1
• Operating system: Redhat EL7.4
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

We use kerberos via apache to authenticate hosts to gitea. Hosts have kerberos principals of the form git/[email protected] which get translated to the username git/host.example.com

When we set ENABLE_REVERSE_PROXY_AUTO_REGISTRATION to true then these accounts are correctly created in gitea when the host runs git commands against our server. However since the account is 'new' it is not in the appropriate teams, so the first run fails, and we then have to set up team membership etc and re-run the processes.

To fix this I'm trying to pre-create these accounts using the UI - however when I try to create a new user with name git/host.example.com I receive the error Username must be valid alphanumeric, dash(-_) or dot characters.

Since auto-generated usernames with these characters seem to work fine, would it be possible to alter this validation to allow a broader range of usernames, filtering only those which would make gitea actually fail?

[lafriks]

/ can not be allowed as that could break functionality and even rise security issues

[mrichar1]

gitea currently allows / in usernames through auto-creation of accounts, and I have several accounts which seem to function correctly with such names. I guess this means that the auto-creation code doesn't follow the same codepath as the UI/API use?

I'm interested to know what security issues might arise from the username containing unexpected characters... I'd hope that all such fields were only ever used with appropriate escaping, with parameterized queries etc to avoid sql injection and similar issues.

I'd obviously be keen to keep / in usernames, since this is useful functionality to us - and I'd argue that it would be better to relax the validation and instead test what actually happens with extra characters.
That way the code can be improved to handle these cases, instead of arbitrarily limiting them because of the unknown effects they might have (especially since, as we can see here, there are unexpected routes to them existing!)

[gszy]

What’s your opinion on allowing @ in usernames?

[lafriks]

Also quite risky to break something. Would all git clients support such urls?

[gszy]

TL; DR: don’t know…

git check-ref-format --branch 'a@a' returns 0, but man git-push doesn’t explain what characters are allowed in path/to/repo (in ssh://[user@]host.xz[:port]/path/to/repo.git/ example). Neither GitHub nor GitLab allow @ in usernames or project names.

@ is commonly used to mention a user or to refer to specific commit. Unless username’s first character is @ or it looks like me@something­‑that­‑looks­‑like­‑commit­‑SHA, that shouldn’t be a very big problem, though it would be if we could refer to branches, like me@master (could be solved with a config option).

[lafriks]

I do think that we should stick to current behaviour to not break things and keep compatibility with future changes (especially if we implement projects/groups under organizations).

[cwchristerw]

I need "-" to work in org name when transferring repo between orgs. When trying to transfer repository from "cwinfo-private" to "warengroup-private". UI will show error "The new owner name is not valid."

[silverwind]

I think we should align our validation for org and repo name to a common denominator among forges like GitHub/GitLab. GitHub for example allow - as repo name, but not as a org name.

The most accurate description of what is allowed in repos is this:

it looks like github allows [A-Za-z0-9_.-], and transforms all other characters to "-".

For orgs:

The name may only contain alphanumeric characters or single hyphens, and cannot begin or end with a hyphen.

[silverwind]

So maybe these, and they could be made configurable I suppose.

• ^[A-Za-z0-9_.-]+$ for repos
• ^(?![-])[A-Za-z0-9]+(?:[-][A-Za-z0-9]+)*?(?<!-)$ for orgs