jenkinsci/jenkins — pull request #1161 by stephenc (2014-03-18 14:30:28+00:00)
Title: Abstract username case sensitivity into an extension point

The current core implementation does not define a proper contract for case insensitivity leading to all sorts of bugs, e.g.

* [JENKINS-22057](https://issues.jenkins-ci.org/browse/JENKINS-22057)
* [JENKINS-12607](https://issues.jenkins-ci.org/browse/JENKINS-12607)
* [JENKINS-3218](https://issues.jenkins-ci.org/browse/JENKINS-3218)
* [JENKINS-9771](https://issues.jenkins-ci.org/browse/JENKINS-9771)
* [JENKINS-6377](https://issues.jenkins-ci.org/browse/JENKINS-6377)
* [JENKINS-20125](https://issues.jenkins-ci.org/browse/JENKINS-20125)
* [JENKINS-18009](https://issues.jenkins-ci.org/browse/JENKINS-18009)

Also there are a lot of issues showing a fundamental misunderstanding of why Jenkins originally used a semi-case insensitive username... (hint the real reason is because windows filesystem is case insensitive)

People seem to think that user ids are case insensitive... despite

* unix logins being case sensitive
* email addresses being case sensitive (yes they are allowed to be... read the RFC... the destination server is allowed to treat them as case sensitive... though the RFC does say a polite version of "only a fool would actually do that" it is allowed by the spec, so you cannot assume that `foo@acme.org` is the same person as `Foo@acme.org`... you can however assume that `foo@acme.org` and `foo@ACME.ORG` are the same person as is `foo@aCmE.OrG` because domain names are not case sensitive)

As such, without a plugable strategy the case sensitive/insensitivity of Jenkins is fundamentally broken.