Skip to content

Obfuscate issue email participants based on member role

Marc Saleiko requested to merge obfuscate-issue-email-participants into master

What does this MR do and why?

Describe in detail what your merge request does and why.

Obfuscates the service_desk_reply_to (aka external_author) email address in the Service Desk issue list and issue detail when the current user is not signed in or has no sufficient role (reporter) in the given project. Also obfuscates issue_email_participants of the issue in the same way.

This is only visible to Service Desk issues in public projects where the confidentiality of a Service Desk issue has been turned off.

General notes to email obfuscation in GitLab

To this date we only use an obfuscated email address on the identity confirmation page (aka "we sent a verification code to OBFUSCATED_EMAIL"). This uses SessionHelpers obfuscated_email method. This method only changes existing characters to * and thus allows to guess the real email address. E.g. see@me.com.uk becomes se*@m*****.uk.

After a discussion we came to the conclusion that it's best to artificially deform the email address and also obfuscate the TLD of the address. The proposed solution is a pattern that uses a fixed number of *, so we cannot tell the real length of the address. E.g. see@me.com.uk becomes se*****@m*****.u**.

See this comment in the discussion for full context.

After this has been merged, you can access this functionality globally in GitLab backend with Gitlab::Utils::Email.obfuscated_email("see@me.com.uk", deform: true).

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

The screenshots are only taken from a public project with SD issues that are not confidential. Here is why:

  • Private projects won't be accessible unauthorized or without a role in the project.
  • A confidential issue won't be accessible unauthorized or without at least Reporter role in the project.

SD issue list

Description Before After
unauthorized (change) image image
no role in project (change) image image
guest role (change) image image
min. reporter role image image

SD issue detail

Description Before After
unauthorized (change) image image
no role in project (change) image image
guest role (change) image image
min. reporter role image image

SD issue detail comment

Description Before After
unauthorized image image
no role in project (change) image image
guest role (change) image image
min. reporter role image image

BTW this also works for multiple issue email participants (did not update the image with the new obfuscation, this is just to showcase the general functionality with more than one participants):

image

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

  1. Add a Service Desk issue or update an issue
i = Project.find_by(name: "Flight").issues.last
i.service_desk_reply_to = "my@mail.com"
i.author = User.support_bot
i.confidential = false
i.save!

IssueEmailParticipant.create!(email: "my@mail.com", issue: i)
  1. Turn confidentiality off for the issue (if it's confidential)
  2. Use a public project or make the project public.
  3. Access GitLab unauthorized
    1. Access the Service Desk issue list and validate SD issue list behavior (by email is obfuscated)
    2. Access the issue's detail page and validate SD issue detail behavior (by email is obfuscated in header)
    3. See that you cannot add a comment to the issue
  4. Access GitLab with a user that does not have a role in the project/group
    1. Access the Service Desk issue list and validate SD issue list behavior (by email is obfuscated)
    2. Access the issue's detail page and validate SD issue detail behavior (by email is obfuscated in header)
    3. Yellow/orange hint box below comment editor shows obfuscated email.
  5. Access GitLab with a user that has at least reporter role in the project/group
    1. Access the Service Desk issue list and validate SD issue list behavior (by email fully readable)
    2. Access the issue's detail page and validate SD issue detail behavior (by email is fully readable in header)
    3. Yellow/orange hint box below comment editor shows fully readable email.
  6. take a sip

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Marc Saleiko

Merge request reports