-
Bug
-
Resolution: Unresolved
-
Minor
-
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.
- duplicates
-
JENKINS-9016 Git creates usernames based on 'name' not the email.
-
- Open
-
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:
This case may not be often encountered but is still a data leak. Making email addresses as ID the default will prevent that.