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

Local-part based user mapping results in confused changelogs

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None

      This is a followup to SECURITY-372 (https://jenkins.io/security/advisory/2017-03-20/#emails-were-sent-to-addresses-not-associated-with-actual-users-of-jenkins-by-mailer-plugin-and-email-extension-plugin)

      A big part of the problem (emails sent to people completely unrelated to what was built) came from the fact that Git plugin tries to map Git users to Jenkins users via the local-part of email addresses.

      This may be a sensible approach in an organization with their own domain and mail server, where everyone is first.last@organization, but outside that narrow situation, it is not. noreply@whatever, github@whatever, info@whatever, the list goes on. Combine with a Jenkins instance building open source projects from various organizations, and you'll Jenkins sending emails to completely wrong people. Now with this issue fixed in the email plugins, what's left is, AFAIUI, a confused changelog inside Jenkins.

      Maybe make the option to use email addresses as ID the default, or do a more sophisticated mapping?

      CC ydubreuil who may be able to fill in some details as he analyzed the problem.

          [JENKINS-42951] Local-part based user mapping results in confused changelogs

          Not much to add, making the option to use email addresses as ID the default is the most sensible thing to do I think.

          Even after the SECURITY-372 fix, we can send email to a wrong person if an organization uses more than one domain in its email suffix and there are collisions on the short name. What ensures the security fix is that the wrong person is also known to Jenkins, so this is much less a concern than sending email to a random person over the internet.

          I tested the following scenario while I was analyzing the security issue:

          • user1 is known to the security realm and has email user1@divisonA.company.org
          • a commit done by user1@divisonB.company.org is built => Git plugin looks up user1 from the security realm and adds it to the culprits
          • an email is sent to user1@divisonA.company.org

          This case may not be often encountered but is still a data leak. Making email addresses as ID the default will prevent that.

          Yoann Dubreuil added a comment - Not much to add, making the option to use email addresses as ID the default is the most sensible thing to do I think. Even after the SECURITY-372 fix, we can send email to a wrong person if an organization uses more than one domain in its email suffix and there are collisions on the short name. What ensures the security fix is that the wrong person is also known to Jenkins, so this is much less a concern than sending email to a random person over the internet. I tested the following scenario while I was analyzing the security issue: user1 is known to the security realm and has email user1@divisonA.company.org a commit done by user1@ divisonB.company .org is built => Git plugin looks up user1 from the security realm and adds it to the culprits an email is sent to user1@ divisonA.company .org This case may not be often encountered but is still a data leak. Making email addresses as ID the default will prevent that.

          Jesse Glick added a comment -

          Duplicate of JENKINS-9016 perhaps? Did not try to follow all the discussions.

          Jesse Glick added a comment - Duplicate of  JENKINS-9016 perhaps? Did not try to follow all the discussions.

            Unassigned Unassigned
            danielbeck Daniel Beck
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: