Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-9016

Git creates usernames based on 'name' not the email.

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • git plugin 1.1.6
      git plugin 2.0, jenkins 1.540, ubuntu 13.10

      I realize mapping git author/commit users back to Jenkin's users is pain, but perhaps it could be done a little better.

      Some ideas:

      • Try looking up a user's email and comparing that.
      • Using the user portion from the email (e.g. someuser@example.com becomes someuser).
      • Looking up the user's email in LDAP, if LDAP is being used.

      The last would be ideal for us.

      Ciao!

          [JENKINS-9016] Git creates usernames based on 'name' not the email.

          Code changed in jenkins
          User: Andrew Bayer
          Path:
          src/main/java/hudson/plugins/git/GitChangeSet.java
          http://jenkins-ci.org/commit/git-plugin/3607d2ec90f69edcf8cedfcb358ce19a980b8f1a
          Log:
          [FIXED JENKINS-9016] If no Jenkins user is found for the commit's user.name value, use the username section of the email address instead.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: src/main/java/hudson/plugins/git/GitChangeSet.java http://jenkins-ci.org/commit/git-plugin/3607d2ec90f69edcf8cedfcb358ce19a980b8f1a Log: [FIXED JENKINS-9016] If no Jenkins user is found for the commit's user.name value, use the username section of the email address instead.

          dogfood added a comment -

          Integrated in plugins_git-plugin #119
          [FIXED JENKINS-9016] If no Jenkins user is found for the commit's user.name value, use the username section of the email address instead.

          Andrew Bayer : 3607d2ec90f69edcf8cedfcb358ce19a980b8f1a
          Files :

          • src/main/java/hudson/plugins/git/GitChangeSet.java

          dogfood added a comment - Integrated in plugins_git-plugin #119 [FIXED JENKINS-9016] If no Jenkins user is found for the commit's user.name value, use the username section of the email address instead. Andrew Bayer : 3607d2ec90f69edcf8cedfcb358ce19a980b8f1a Files : src/main/java/hudson/plugins/git/GitChangeSet.java

          Code changed in jenkins
          User: Andrew Bayer
          Path:
          src/test/java/hudson/plugins/git/AbstractGitTestCase.java
          http://jenkins-ci.org/commit/git-plugin/12515a33b7ae0e8030fbc61575e6cd445850ceb2
          Log:
          Fixing test failures due to JENKINS-9016 fix.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: src/test/java/hudson/plugins/git/AbstractGitTestCase.java http://jenkins-ci.org/commit/git-plugin/12515a33b7ae0e8030fbc61575e6cd445850ceb2 Log: Fixing test failures due to JENKINS-9016 fix.

          Joel Hough added a comment -

          I'm still having issues with this.
          In my setup, we use ldap for authentication. The ldap username has almost no similarity to the author name or email in our git commits (we use full and proper "Firstname Lastname <Firstname.Lastname@Companyname.com>" for that).
          What would work is searching for existing users by email address rather than using the email segment as a username, since the ldap plugin does properly set the email field to the same address as is listed in the git commit (assuming case insensitivity).

          Joel Hough added a comment - I'm still having issues with this. In my setup, we use ldap for authentication. The ldap username has almost no similarity to the author name or email in our git commits (we use full and proper "Firstname Lastname <Firstname.Lastname@Companyname.com>" for that). What would work is searching for existing users by email address rather than using the email segment as a username, since the ldap plugin does properly set the email field to the same address as is listed in the git commit (assuming case insensitivity).

          Jean-Sébastien Pédron added a comment - - edited

          I agree with Joel's comment.

          In our setup, only users changing their full name in Jenkins to match the one in Git have their commits associated. Other people have two "accounts": the one they use to authenticate (LDAP) and the one automatically created with Git commits.

          Using the e-mail address to do the mapping seems to be a better solution.

          Jean-Sébastien Pédron added a comment - - edited I agree with Joel's comment. In our setup, only users changing their full name in Jenkins to match the one in Git have their commits associated. Other people have two "accounts": the one they use to authenticate (LDAP) and the one automatically created with Git commits. Using the e-mail address to do the mapping seems to be a better solution.

          Jan Vansteenkiste added a comment - - edited

          I have created some initial code on this subject. The only question that remains is whether the plugin is the right place for my UserEmailResolver.
          I also had some troubles getting the tests going and had to add a newer jenkins-core, ui-samples-plugin, jenkins-test-harness and javadoc to the dependencies.

          https://github.com/vStone/git-plugin/commit/63612268d832edc7a77d0be55e650e31fc5442a9

          Jan Vansteenkiste added a comment - - edited I have created some initial code on this subject. The only question that remains is whether the plugin is the right place for my UserEmailResolver. I also had some troubles getting the tests going and had to add a newer jenkins-core, ui-samples-plugin, jenkins-test-harness and javadoc to the dependencies. https://github.com/vStone/git-plugin/commit/63612268d832edc7a77d0be55e650e31fc5442a9

          In my setup I have users authenticated against corporate Active Directory, which works nice along with LDAP email plugin (email addresses get resolved correctly). User ids look something like 123456, and as such are defined in Global Security. Real user names do get resolved correctly from those numeric ids.
          Unfortunatelly, when it comes to build changes list of the git based projects, the real user names do not get resolved correctly as they do not contain those numeric ids any more. For the commiter/author "Dominik Drzewiecki <dominik.drzewiecki@acme.com>" which is a concatenation of git user.name and user.email configuration parameters I get the changelog entry commited by dominik.drzewiecki which cannot be futher resolved either against AD (id) or LDAP (email). It seems that Jan's patch that adds one extra resolution step would do the trick.

          Dominik Drzewiecki added a comment - In my setup I have users authenticated against corporate Active Directory, which works nice along with LDAP email plugin (email addresses get resolved correctly). User ids look something like 123456, and as such are defined in Global Security. Real user names do get resolved correctly from those numeric ids. Unfortunatelly, when it comes to build changes list of the git based projects, the real user names do not get resolved correctly as they do not contain those numeric ids any more. For the commiter/author "Dominik Drzewiecki <dominik.drzewiecki@acme.com>" which is a concatenation of git user.name and user.email configuration parameters I get the changelog entry commited by dominik.drzewiecki which cannot be futher resolved either against AD (id) or LDAP (email). It seems that Jan's patch that adds one extra resolution step would do the trick.

          Nathan Nutter added a comment - - edited

          The only two "modes" at the moment (v2.0) seem to be either user.name or user.email not the username from user.email? The latter being the suggested default "mode" in v1.1.7:

          If no Jenkins user is found for a commit's user.name value, strip the username from "username@domain.com" from the user.email value and use that instead.

          We want users to be associated with just their username not their full email and not their user.name so that other things can automatically work, e.g. the Jabber Plugin. Also, the users log in, via LDAP, with just their username.

          Nathan Nutter added a comment - - edited The only two "modes" at the moment (v2.0) seem to be either user.name or user.email not the username from user.email? The latter being the suggested default "mode" in v1.1.7: If no Jenkins user is found for a commit's user.name value, strip the username from "username@domain.com" from the user.email value and use that instead. We want users to be associated with just their username not their full email and not their user.name so that other things can automatically work, e.g. the Jabber Plugin. Also, the users log in, via LDAP, with just their username.

          Andréas Berg added a comment - - edited

          The unique identifier in git is the e-mail address so matching towards a Jenkins account on user name is really bad. In some cases, like for example push-review tests with Gerrit, you do not need to match to a Jenkins account at all, just use the e-mail address in the commit when sending feedback.

          Option #1 (Try looking up a user's email and comparing that.) is definitely the way this should be implemented.
          Option #3 (Looking up the user's email in LDAP, if LDAP is being used.) would be a great bonus.

          Option #2 (Using the user portion from the email (e.g. someuser@example.com becomes someuser).) is just as bad is matching on user name and solves nothing.

          We are a big company with a lot of people, some do have the exact same names so now we have users getting e-mail feedback on git commits they are not the author of.

          Andréas Berg added a comment - - edited The unique identifier in git is the e-mail address so matching towards a Jenkins account on user name is really bad. In some cases, like for example push-review tests with Gerrit, you do not need to match to a Jenkins account at all, just use the e-mail address in the commit when sending feedback. Option #1 (Try looking up a user's email and comparing that.) is definitely the way this should be implemented. Option #3 (Looking up the user's email in LDAP, if LDAP is being used.) would be a great bonus. Option #2 (Using the user portion from the email (e.g. someuser@example.com becomes someuser).) is just as bad is matching on user name and solves nothing. We are a big company with a lot of people, some do have the exact same names so now we have users getting e-mail feedback on git commits they are not the author of.

          Problem still persists.
          In my company users are uniquely identified by their email adress not their user.name, so extracting the user name from the email does not work either. Any plans when to fix that?

          Daniel Geißler added a comment - Problem still persists. In my company users are uniquely identified by their email adress not their user.name, so extracting the user name from the email does not work either. Any plans when to fix that?

          René Scheibe added a comment -

          I have seen that the issue had some activity recently. (I came here due to JENKINS-43178.)

          I agree with epkabeg and joel. I would really be happy if the issue could be fixed as proposed in option #1 and #3.

          Btw. there is already this global plugin option that uses the full email address:
          Create new accounts based on author/committer's email
          As git changelog is parsed to identify authors/committers and populate Jenkins user database, use email as ID for new users.

          René Scheibe added a comment - I have seen that the issue had some activity recently. (I came here due to JENKINS-43178 .) I agree with epkabeg and joel . I would really be happy if the issue could be fixed as proposed in option #1 and #3. Btw. there is already this global plugin option that uses the full email address: Create new accounts based on author/committer's email As git changelog is parsed to identify authors/committers and populate Jenkins user database, use email as ID for new users.

          With the recent security fixes (e.g. JENKINS-43178) the situation is getting even worse.

          Looking up a user based on it's configured email-address should solve so many problems.

          Expecting to have the login user names matching exactly the mail adress before the @ is just too restrictive. Guess someone changing it's mail but keeping it's account or like in my company having short login names (coming from ldap) contrary to long mail addresses.

          abayer please consider raising the priority of this task!

          Daniel Geißler added a comment - With the recent security fixes (e.g.  JENKINS-43178 ) the situation is getting even worse. Looking up a user based on it's configured email-address should solve so many problems. Expecting to have the login user names matching exactly the mail adress before the @ is just too restrictive. Guess someone changing it's mail but keeping it's account or like in my company having short login names (coming from ldap) contrary to long mail addresses. abayer please consider raising the priority of this task!

          I second the Option #1 (and #3) above.

          We are authenticating against LDAP and have rather arbitrary Jenkins user id s- e.g. fuu12bar5.

          The only thing the "real" LDAP users and the git users have in common is the email address (if you are willing to compare it case insensitive).

          Is this the right part of the code?
          https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L387

          There is a really old pull request, mentioned in this comment, might this be still useful?

           

          Benjamin Herbert added a comment - I second the Option #1 (and #3) above. We are authenticating against LDAP and have rather arbitrary Jenkins user id s- e.g. fuu12bar5. The only thing the "real" LDAP users and the git users have in common is the email address (if you are willing to compare it case insensitive). Is this the right part of the code? https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L387 There is a really old pull request, mentioned in this comment , might this be still useful?  

          Jose Camacho added a comment -

          I came to the situation described by others here, in our case jenkins users being handled using Active Directory (AD) and commit information coming from GIT (Bitbucket). For a user with my username (Jose Camacho), commit information from GIT included in "Author" part would have the username defined as jose.camacho but users in AD are created using acronyms like jocam (for jose camacho).

          My Email address is matched with both users (jose.camacho and jocam), and when trying to send out emails to me, it detects that the user name is jose.camacho (and not jocam!) and when using the realm validation mechanism (AD), AD says "not existing user" and the message "Not sending mail to unregistered user" appears.

          For the options that epkabeg suggested, I also second Option #1: If there is any kind of user with that email address, why should it be declared as "unregister user"?

          – Workaround

          Anyway, we are sending Emails from Jenkinsfile using emailext and we did not want to change that way of using Jenkins so we are using right now a "workaround".

          We know that the Emails information coming from GIT is correct (close, controled environment) so we disable the "not sending mail to unregistered user" by using a variable included in the EmailExt plugin version 2.58, introducing following code:

          def currenVal = RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS

          RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS  = true

          // Send Email with emailext

          RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS = currenVal

          (this needs to include import hudson.plugins.emailext.plugins.recipients.* and also needs a securiy confirmation)

          I know, it is not the better solution, but it works. Hope this helps anyone looking for a workaround.

          Jose Camacho added a comment - I came to the situation described by others here, in our case jenkins users being handled using Active Directory (AD) and commit information coming from GIT (Bitbucket). For a user with my username (Jose Camacho), commit information from GIT included in "Author" part would have the username defined as jose.camacho but users in AD are created using acronyms like jocam (for jose camacho). My Email address is matched with both users (jose.camacho and jocam), and when trying to send out emails to me, it detects that the user name is jose.camacho (and not jocam!) and when using the realm validation mechanism (AD), AD says "not existing user" and the message "Not sending mail to unregistered user" appears. For the options that  epkabeg  suggested, I also second Option #1: If there is any kind of user with that email address, why should it be declared as "unregister user"? – Workaround Anyway, we are sending Emails from Jenkinsfile using emailext and we did not want to change that way of using Jenkins so we are using right now a "workaround". We know that the Emails information coming from GIT is correct (close, controled environment) so we disable the "not sending mail to unregistered user" by using a variable included in the EmailExt plugin version 2.58, introducing following code: def currenVal = RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS  = true // Send Email with emailext RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS = currenVal (this needs to include import hudson.plugins.emailext.plugins.recipients.* and also needs a securiy confirmation) I know, it is not the better solution, but it works. Hope this helps anyone looking for a workaround.

          Daniel Geißler added a comment - - edited

          jose_camacho we have a very similar setup in my company. We also see that multiple users with the same email are created (one from AD when the user loges in, the other from git plugin).

          What we found was that having the git authors name matching the AD displayName seems to associate the users correctly (that can be seen in the projects changes too). If i remember correctly, when you are using Bitbucket with AD, you can enforce that name matching in all commits.

          Still a matching based on the email adress would be so much more convenient.

           

          EDIT: rechecked the association and it seems to work only in special cases, that i have to investigate further, as of today we are stuck to the system property to allow everything too.

          Daniel Geißler added a comment - - edited jose_camacho we have a very similar setup in my company. We also see that multiple users with the same email are created (one from AD when the user loges in, the other from git plugin). What we found was that having the git authors name matching the AD displayName seems to associate the users correctly (that can be seen in the projects changes too). If i remember correctly, when you are using Bitbucket with AD, you can enforce that name matching in all commits. Still a matching based on the email adress would be so much more convenient.   EDIT: rechecked the association and it seems to work only in special cases, that i have to investigate further, as of today we are stuck to the system property to allow everything too.

          Yves Schumann added a comment -

          We struggle on this issue too and in my opinion this ist not a minor issue, it's more an incident! Actually the issue is some kind of a show stopper as the user did not receive proper notifications anymore.

          Yves Schumann added a comment - We struggle on this issue too and in my opinion this ist not a minor issue, it's more an incident ! Actually the issue is some kind of a show stopper as the user did not receive proper notifications anymore.

          We also struggle on this issue, any progress ?

          Antoine Le Maire added a comment - We also struggle on this issue, any progress ?

          Code changed in jenkins
          User: George
          Path:
          src/main/java/hudson/plugins/emailext/ExtendedEmailPublisherDescriptor.java
          src/main/java/hudson/plugins/emailext/plugins/recipients/RecipientProviderUtilities.java
          src/main/resources/hudson/plugins/emailext/ExtendedEmailPublisher/global.groovy
          src/main/webapp/help/globalConfig/allowUnregistered.html
          http://jenkins-ci.org/commit/email-ext-plugin/19081b2aa3d32c479125b538c545fdd3065960f8
          Log:
          JENKINS-43268 adding global checkbox to allow sending to unregistered emails. This is a workaround to a SCM plugin issue, like JENKINS-9016 and probably others (#161)

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: George Path: src/main/java/hudson/plugins/emailext/ExtendedEmailPublisherDescriptor.java src/main/java/hudson/plugins/emailext/plugins/recipients/RecipientProviderUtilities.java src/main/resources/hudson/plugins/emailext/ExtendedEmailPublisher/global.groovy src/main/webapp/help/globalConfig/allowUnregistered.html http://jenkins-ci.org/commit/email-ext-plugin/19081b2aa3d32c479125b538c545fdd3065960f8 Log: JENKINS-43268 adding global checkbox to allow sending to unregistered emails. This is a workaround to a SCM plugin issue, like JENKINS-9016 and probably others (#161)

          Would it be possible to have some kind of 'domain filter' when you enable the 'Allow sending to unregistered users' checkbox?

          For instance: allow sending mails to contributers to a git repo that don't have a Jenkins account, but that do have an email address set up that ends with '@domain.com'.

          This would be interesting so that when we're using open source git(hub) repositories we don't accidentally sent out mails to the contributers there, when one of our builds fail.

          Patrick Van Brussel added a comment - Would it be possible to have some kind of 'domain filter' when you enable the 'Allow sending to unregistered users' checkbox? For instance: allow sending mails to contributers to a git repo that don't have a Jenkins account, but that do have an email address set up that ends with '@domain.com'. This would be interesting so that when we're using open source git(hub) repositories we don't accidentally sent out mails to the contributers there, when one of our builds fail.

          Can't the e-mail address(es) in the commit message be used to find Jenkins security realm users?

          The e-mail address in my commit messages is the same as the e-mail address associated with my Jenkins account.  Why can those not be matched up?

          Brian J Murrell added a comment - Can't the e-mail address(es) in the commit message be used to find Jenkins security realm users? The e-mail address in my commit messages is the same as the e-mail address associated with my Jenkins account.  Why can those not be matched up?

          I agree with everyone else here. We just started converting from old jobs to Pipeline jobs and are now faced with issues surrounding user mapping. I'll admit, it's probably more due to the fact we updated our 3 years old Jenkins instance.

          The unique identifier IS the email address. This is what should be used for mapping with registered Jenkins user. As many others, our company use shorthand names for login in AD, yet in Git all our users configure their full name. This is a common practice in the corporate world at it makes it easy to login everywhere with a shorter name. In my case it's even a lifesaver.
          Imagine if I had to type "Jeremie.Faucher-Goulet" every time I log in somewhere, instead of the much easier "jfaucher" I use against AD in all login forms everywhere.

          Even Fisheye+Crucible from Atlassian is able to do proper mapping between AD and git committer based on emails.

          I feel this is really needed, as I don't like disabling the security check against registered Jenkins users.... We did have in the past a few cases of embarrassing leaked emails from Jenkins because we compile 3rd party applications and committers outside the organization appeared as the culprits in some failed builds. Until Jenkins does proper user mapping based on email we are vulnerable to this issue because we are forced to disable the security feature in the meantime.

          Jérémie Faucher-Goulet added a comment - I agree with everyone else here. We just started converting from old jobs to Pipeline jobs and are now faced with issues surrounding user mapping. I'll admit, it's probably more due to the fact we updated our 3 years old Jenkins instance. The unique identifier IS the email address. This is what should be used for mapping with registered Jenkins user. As many others, our company use shorthand names for login in AD, yet in Git all our users configure their full name. This is a common practice in the corporate world at it makes it easy to login everywhere with a shorter name. In my case it's even a lifesaver. Imagine if I had to type "Jeremie.Faucher-Goulet" every time I log in somewhere, instead of the much easier "jfaucher" I use against AD in all login forms everywhere. Even Fisheye+Crucible from Atlassian is able to do proper mapping between AD and git committer based on emails. I feel this is really needed, as I don't like disabling the security check against registered Jenkins users.... We did have in the past a few cases of embarrassing leaked emails from Jenkins because we compile 3rd party applications and committers outside the organization appeared as the culprits in some failed builds. Until Jenkins does proper user mapping based on email we are vulnerable to this issue because we are forced to disable the security feature in the meantime.

          I was just hit by the same issue. E-mail should be compared against e-mail field, not processed and compared against some different field. Or at least please give an option to choose the behaviour.

          Bartosz Błaszkiewicz added a comment - I was just hit by the same issue. E-mail should be compared against e-mail field, not processed and compared against some different field. Or at least please give an option to choose the behaviour.

          Hopefully this bumps this thread. I am in the exact same spot as jeremfg.
          Since this ticket looks like its stuck in limbo, did anyone find any solution to this?

          Matjaž Matjašec added a comment - Hopefully this bumps this thread. I am in the exact same spot as jeremfg . Since this ticket looks like its stuck in limbo, did anyone find any solution to this?

          Uv Wild added a comment - - edited

          BUMP TOO

          we have 6 companies working on the machine.
          You wont believe what funny names show up in the commiter list of asynchPeople.

          This is ABSOLUTELY not an option for a secure environment.  

          The aysncList we see there is neither injective and can be used to identify, nor is it surjective and I can be sure that my git server will contain the entry as this is the job of the gitserver which might not keep all the user.name 's used by its users over time.

          This is REALLY WRONG!!!

          Uv Wild added a comment - - edited BUMP TOO we have 6 companies working on the machine. You wont believe what funny names show up in the commiter list of asynchPeople. This is ABSOLUTELY not an option for a secure environment.   The aysncList we see there is neither injective and can be used to identify, nor is it surjective and I can be sure that my git server will contain the entry as this is the job of the gitserver which might not keep all the user.name 's used by its users over time. This is REALLY WRONG!!!

          Ben Spoor added a comment -

          🙄 facing the same issues as described above

           

           

           

          Ben Spoor added a comment - 🙄 facing the same issues as described above      

          Ben Spoor added a comment -

          As a workaround I've used the field "Allowed Domains" of the email-ext plugin.

          Ben Spoor added a comment - As a workaround I've used the field "Allowed Domains" of the email-ext plugin.

          R. Fitzner added a comment - - edited

          The first time I run into the issue
          "Not sending mail to unregistered user abc@xyz.com because your SCM claimed this was associated with a user ID `` which your security realm does not recognize; you may need changes in your SCM plugin."
          (see https://docs.cloudbees.com/docs/cloudbees-ci-kb/latest/client-and-managed-masters/not-sending-mail-to-unregistered-user-associated-with-scm)
          was all developers had to change their email address to a new domain.
          Even after telling them to update the email address in their Jenkins account, it did not really fix the issue for all developers.

          After checking the source code https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java
          and doing some tests according to the source code, I came to the following results:

           

          Jenkins always creates new Jenkins user accounts nevertheless if "Create new accounts based on author/committer's email?" is checked:

          https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L468

             user = getUser(csAuthorEmail, true);
          }
          if (user != null && setUserDetails) {
             user.setFullName(csAuthor);
          

          ... or not checked:

          https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L502

          user = getUser(emailParts[0], true);
          

           

          Use case A:

          At the beginning the Jenkins server was running with "Create new accounts based on author/committer's email?" false.
          The result is that some developers have got 2 Jenkins accounts now:

          UserID 1: "firstname.lastname" (auto-created account by GitChangeSet)
          UserID 2: "lastname" ("lastname" is in my company the user name for the Jenkins login and matches the LDAP account and is dependent on your company's policy)

          I guess this happens when a developer logs into Jenkins after pushing his/her first commit.

           

          Use case B:

          Later all developers have updated their email address for UserID 2, but not in UserID 1. Which fixed the issue for some developers,
          but not for all because:

          https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L488

          user = getUser(csAuthor, false);
          

          is looking for the ID or FullName of all Jenkins accounts that matches the extracted "user.name" of the author commit
          (e.g. "Firstname LASTNAME <firstname.lastname@mycompany.com>" -> "user.name" = "Firstname LASTNAME").
          and this comparison is case sensitive!
          One little typo and the account "does not exist" although it exists and then a new account will be created with "firstname.lastname" (as ID and Full Name)!

          You can test it via "Script Console" in Jenkins, e.g. like this:

          def u = User.get('lastname', false, Collections.emptyMap()) // my company LDAP ID
          //def u = User.get('Firstname LASTNAME', false, Collections.emptyMap()) // Full Name of my authorized LDAP Jenkins account (CASE-SENSITIVE!)
          //def u = User.get('firstname.lastname', false, Collections.emptyMap()) // auto-created account from initial pushed commit
          return "id = " + u.getId() + ", FullName = " + u.getFullName() + ", no. of authorities = " + u.getAuthorities()?.size()
          

          Lets assume there is a little typo between Jenkins account FullName and author commit
          (which is a quite common practice in developers life because "git config user.name" is not always set correctly for all dev-tools and environments) then this line will be used:
          https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L499

          String[] emailParts = csAuthorEmail.split("@");
          if (emailParts.length > 0) {
             try {
                user = getUser(emailParts[0], true);
          

          And this is for my company (LDAP policy) always the UN-authorized Jenkins User Account!

           

          Improvement B.1)
          In my opinion to improve here the functionality of enabling/disabling "auto-create user account" should be implemented.
          From a security point of view this ends up in the same situation:
             no account -> no email will be send
             no authorized account -> no email will be send

          Improvement B.2)
          Another improvement could be that

             user = getUser(csAuthor, false);
          

          is looking for matching Full Names but with case-insensitivity.

          Improvement B.3)
          Another improvement could be (if auto-creating is enabled):

             // check 
             user = getUser(emailParts[0], false);
             // if not then create
             user = getUser(emailParts[0], true);
             // and update the user with the extracted user.name and user.email of the author commit:
             user.setFullName(csAuthor);
             setMail(user, csAuthorEmail);
          

          OR in respect of this ticket here instead of creating "firstname.lastname" let's take the extracted author name:

             // check and if not then create
             user = getUser(csAuthor, true);
             // and update the user with the extracted user.email of the author commit:
             setMail(user, csAuthorEmail);
          

          Improvement B.4)
          If
             "Create new accounts based on author/committer's email?" false
             "Use existing account with same email if found?" true
          then before Improvement suggestion B.3 search for accounts with the same email address.
          The code here https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L458 and ff. can be re-used.

           

          Use case C:

          Later my company changed the LDAP policy (1-to-n characters of the firstname plus lastname) and now things got really bad.
          So I changed the Jenkins server setting to:
             "Create new accounts based on author/committer's email?" true
             "Use existing account with same email if found?" true
          because I read it might fix the issue. But in real life for some developers it doesn't work either.

          And the reason is there is a loop in the source code:

          https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L459

          for(User existingUser : User.getAll()) {
             if (csAuthorEmail.equalsIgnoreCase(getMail(existingUser))) {
                 user = existingUser;
                 setUserDetails = false;
                 break; // this line is a real problem
              }
          }
          

          and it stops searching as soon as it got the first UserID with the matching email address.

          In real life some developers have got 3 Jenkins accounts now:

             user.name = "Firstname LASTNAME"
             user.email = "firstname.lastname@mycompany.com"
             author commit = "Firstname LASTNAME <firstname.lastname@mycompany.com>"
             LDAP/AD = "lastname"
             
             UserID 1: "firstname.lastname" (from use case A or use case B)
             UserID 2: "firstname.lastname@mycompany.com" (from use case B)
             UserID 3: "lastname" (authorized by LDAP)

          Well, UserID 1 and 2 are both smaller than UserID 3 ("firstname.lastname" < ""firstname.lastname@mycompany.com"" < "lastname")
          and that's why for some users the UN-authorized UserID 1 or 2 are always taken and not the authorized account UserID 3.

          You can test it via "Script Console" in Jenkins, e.g. like this:

          def u = []
          for (User existingUser : User.getAll()) {
            if ('firstname.lastname@mycompany.com'.equalsIgnoreCase(existingUser.getProperty(hudson.tasks.Mailer.UserProperty.class).getExplicitlyConfiguredAddress())) {
               u += existingUser.getId() + " : " + existingUser.getFullName() + " (" + existingUser.getAuthorities().size() + ")"
               //break // this line is a real problem
             }
          }
          return u
          

           

          Improvement C.1)

          So a quick bug fix (see line 460) could look like this:

          for(User existingUser : User.getAll()) {
             if (csAuthorEmail.equalsIgnoreCase(getMail(existingUser)) && existingUser.getAuthorities().size() > 0) { // line 460
                 user = existingUser;
                 setUserDetails = false;
                 break;
              }
          }
          

           

          Summary:

          As long as the source code is not improved and you don't want to check "Allow sending to unregistered users" then the only workaround is:

          Either my company adapts the LDAP policy to the Jenkins logic:

          firstname.lastname@mycompany.com
          or
          firstname.lastname

          OR

          to disable "Create new accounts based on author/committer's email?" and tell a developers:

          log into Jenkins and make sure that:

          git user.name = jenkins.fullname (CASE-SENSITIVE!)
          git user.email = jenkins.email

          R. Fitzner added a comment - - edited The first time I run into the issue "Not sending mail to unregistered user abc@xyz.com because your SCM claimed this was associated with a user ID `` which your security realm does not recognize; you may need changes in your SCM plugin." (see https://docs.cloudbees.com/docs/cloudbees-ci-kb/latest/client-and-managed-masters/not-sending-mail-to-unregistered-user-associated-with-scm ) was all developers had to change their email address to a new domain. Even after telling them to update the email address in their Jenkins account, it did not really fix the issue for all developers. After checking the source code https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java and doing some tests according to the source code, I came to the following results:   Jenkins always creates new Jenkins user accounts nevertheless if "Create new accounts based on author/committer's email?" is checked: https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L468    user = getUser(csAuthorEmail, true ); } if (user != null && setUserDetails) {    user.setFullName(csAuthor); ... or not checked: https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L502 user = getUser(emailParts[0], true );   Use case A: At the beginning the Jenkins server was running with "Create new accounts based on author/committer's email?" false. The result is that some developers have got 2 Jenkins accounts now: UserID 1: "firstname.lastname" (auto-created account by GitChangeSet) UserID 2: "lastname" ("lastname" is in my company the user name for the Jenkins login and matches the LDAP account and is dependent on your company's policy) I guess this happens when a developer logs into Jenkins after pushing his/her first commit.   Use case B: Later all developers have updated their email address for UserID 2, but not in UserID 1. Which fixed the issue for some developers, but not for all because: https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L488 user = getUser(csAuthor, false ); is looking for the ID or FullName of all Jenkins accounts that matches the extracted "user.name" of the author commit (e.g. "Firstname LASTNAME <firstname.lastname@mycompany.com>" -> "user.name" = "Firstname LASTNAME"). and this comparison is case sensitive! One little typo and the account "does not exist" although it exists and then a new account will be created with "firstname.lastname" (as ID and Full Name)! You can test it via "Script Console" in Jenkins, e.g. like this: def u = User.get( 'lastname' , false , Collections.emptyMap()) // my company LDAP ID //def u = User.get( 'Firstname LASTNAME' , false , Collections.emptyMap()) // Full Name of my authorized LDAP Jenkins account (CASE-SENSITIVE!) //def u = User.get( 'firstname.lastname' , false , Collections.emptyMap()) // auto-created account from initial pushed commit return "id = " + u.getId() + ", FullName = " + u.getFullName() + ", no. of authorities = " + u.getAuthorities()?.size() Lets assume there is a little typo between Jenkins account FullName and author commit (which is a quite common practice in developers life because "git config user.name" is not always set correctly for all dev-tools and environments) then this line will be used: https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L499 String [] emailParts = csAuthorEmail.split( "@" ); if (emailParts.length > 0) {     try {       user = getUser(emailParts[0], true ); And this is for my company (LDAP policy) always the UN-authorized Jenkins User Account!   Improvement B.1) In my opinion to improve here the functionality of enabling/disabling "auto-create user account" should be implemented. From a security point of view this ends up in the same situation:    no account -> no email will be send    no authorized account -> no email will be send Improvement B.2) Another improvement could be that    user = getUser(csAuthor, false ); is looking for matching Full Names but with case-insensitivity. Improvement B.3) Another improvement could be (if auto-creating is enabled):     // check     user = getUser(emailParts[0], false );     // if not then create    user = getUser(emailParts[0], true );     // and update the user with the extracted user.name and user.email of the author commit:    user.setFullName(csAuthor);    setMail(user, csAuthorEmail); OR in respect of this ticket here instead of creating "firstname.lastname" let's take the extracted author name:     // check and if not then create    user = getUser(csAuthor, true );     // and update the user with the extracted user.email of the author commit:    setMail(user, csAuthorEmail); Improvement B.4) If    "Create new accounts based on author/committer's email?" false    "Use existing account with same email if found?" true then before Improvement suggestion B.3 search for accounts with the same email address. The code here https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L458 and ff. can be re-used.   Use case C: Later my company changed the LDAP policy (1-to-n characters of the firstname plus lastname) and now things got really bad. So I changed the Jenkins server setting to:    "Create new accounts based on author/committer's email?" true    "Use existing account with same email if found?" true because I read it might fix the issue. But in real life for some developers it doesn't work either. And the reason is there is a loop in the source code: https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L459 for (User existingUser : User.getAll()) {     if (csAuthorEmail.equalsIgnoreCase(getMail(existingUser))) {       user = existingUser;       setUserDetails = false ;       break ; // this line is a real problem    } } and it stops searching as soon as it got the first UserID with the matching email address. In real life some developers have got 3 Jenkins accounts now:    user.name = "Firstname LASTNAME"    user.email = "firstname.lastname@mycompany.com"    author commit = "Firstname LASTNAME <firstname.lastname@mycompany.com>"    LDAP/AD = "lastname"        UserID 1: "firstname.lastname" (from use case A or use case B)    UserID 2: "firstname.lastname@mycompany.com" (from use case B)    UserID 3: "lastname" (authorized by LDAP) Well, UserID 1 and 2 are both smaller than UserID 3 ("firstname.lastname" < ""firstname.lastname@mycompany.com"" < "lastname") and that's why for some users the UN-authorized UserID 1 or 2 are always taken and not the authorized account UserID 3. You can test it via "Script Console" in Jenkins, e.g. like this: def u = [] for (User existingUser : User.getAll()) {   if ( 'firstname.lastname@mycompany.com' .equalsIgnoreCase(existingUser.getProperty(hudson.tasks.Mailer.UserProperty.class).getExplicitlyConfiguredAddress())) {     u += existingUser.getId() + " : " + existingUser.getFullName() + " (" + existingUser.getAuthorities().size() + ")"     // break // this line is a real problem   } } return u   Improvement C.1) So a quick bug fix (see line 460) could look like this: for (User existingUser : User.getAll()) {     if (csAuthorEmail.equalsIgnoreCase(getMail(existingUser)) && existingUser.getAuthorities().size() > 0) { // line 460       user = existingUser;       setUserDetails = false ;       break ;    } }   Summary: As long as the source code is not improved and you don't want to check "Allow sending to unregistered users" then the only workaround is: Either my company adapts the LDAP policy to the Jenkins logic: firstname.lastname@mycompany.com or firstname.lastname OR to disable "Create new accounts based on author/committer's email?" and tell a developers: log into Jenkins and make sure that: git user.name = jenkins.fullname (CASE-SENSITIVE!) git user.email = jenkins.email

          R. Fitzner added a comment -

          UPDATE:

          My own Improvement suggestion B.3 will also not work and the reason is:

          def u = User.get('Firstname LASTNAME', false, Collections.emptyMap())

          always returns the first UserID if all 2 or 3 Jenkins accounts have the same Full Name 'Firstname LASTNAME':

          UserID 1: "firstname.lastname" (fullName "Firstname LASTNAME", I changed it afterwards as admin just for testing)
          UserID 2: "firstname.lastname@mycompany.com" (fullName "Firstname LASTNAME" extracted user.name and set by auto-create)
          UserID 3: "lastname" (fullName "Firstname LASTNAME" set by developer)

          So auto-creating a new user and extracting the user.name and updating it as FullName
          https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L471

          is also not good if you want to use:

          user = getUser(csAuthor, false);

          later (after disabling "Create new accounts based on author/committer's email").

          So Improvement suggestion B.1 enabling/disabling "auto-create user account" and cleaning-up UN-authorized Jenkins accounts later seems to me the only working solution here, unless deeper Jenkins core and/or LDAP plugin improvements will be provided here by experts.

          R. Fitzner added a comment - UPDATE: My own Improvement suggestion B.3 will also not work and the reason is: def u = User.get( 'Firstname LASTNAME' , false , Collections.emptyMap()) always returns the first UserID if all 2 or 3 Jenkins accounts have the same Full Name 'Firstname LASTNAME': UserID 1: "firstname.lastname" (fullName "Firstname LASTNAME", I changed it afterwards as admin just for testing) UserID 2: "firstname.lastname@mycompany.com" (fullName "Firstname LASTNAME" extracted user.name and set by auto-create) UserID 3: "lastname" (fullName "Firstname LASTNAME" set by developer) So auto-creating a new user and extracting the user.name and updating it as FullName https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L471 is also not good if you want to use: user = getUser(csAuthor, false ); later (after disabling "Create new accounts based on author/committer's email"). So Improvement suggestion B.1 enabling/disabling "auto-create user account" and cleaning-up UN-authorized Jenkins accounts later seems to me the only working solution here, unless deeper Jenkins core and/or LDAP plugin improvements will be provided here by experts.

          We recently tripped over this -  to me, the code should look for a user that is using the email address of the culprit rather than clumsily trying to guess at a username to match with - in our case, we may have some meta data pumped into the Full names by the directory management team.

          I'm curious what would be the knock on effects of having the culprit code use  hudson.tasks.Mailer.UserProperty(csAuthorEmail) and searching for a match among all users.

          Matthew Ludlum added a comment - We recently tripped over this -  to me, the code should look for a user that is using the email address of the culprit rather than clumsily trying to guess at a username to match with - in our case, we may have some meta data pumped into the Full names by the directory management team. I'm curious what would be the knock on effects of having the culprit code use  hudson.tasks.Mailer.UserProperty(csAuthorEmail) and searching for a match among all users.

            Unassigned Unassigned
            docwhat Christian Höltje
            Votes:
            51 Vote for this issue
            Watchers:
            61 Start watching this issue

              Created:
              Updated: