Enable S/MIME encryption for email notifications
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Release notes
You'll now have the ability to secure your sensitive information with S/MIME encryption for email notifications in GitLab. This feature ensures that confidential data, such as release dates, bugs, and future product ideas remains protected end-to-end, giving you peace of mind about the security of your project information.
Problem to solve
GitLab offers a good and secure design:
- hosting data on-premise
- Git data transfer via SSH or HTTPS
- Accessing GitLab WebUI via HTTPS
- Setting access rights per group and project
- Confidential issues
Unfortunately there is a hole when it comes to external partners and customers: If an external partner or customer uses his companies email address or even private email address, the secure chain of information flow is broken by the SMTP protocol. The majority of SMTP servers, does not support encrypted server to server communication. Even many would support it, GitLab can not ensure that issues texts, code reviews and other confidential information is protected on every hop from GitLab to the end users mail program.
These unencrypted emails may contain:
- release dates, release delays
- bugs, vulnerabilities, security issues
- classified code, classified values
- future product ideas
A solution is needed to allow GitLab to securely transmit sensitive information to customers to ensure it is protected end-to-end.
Proposal
Must have
- Allow a user to add their public S/MIME certificate to their account
- When a user has supplied an S/MIME certificate, encrypt all outbound email notifications to that user
- Introduce a new instance-level setting to allow administrators to require S/MIME encryption for all users
Should have
- When an administrator has required S/MIME encryption, redact the email body when sending notifications to users that have not yet provided their S/MIME certificate
- Notify end users when their S/MIME certificate is about to expire, and again when it does expire. (Akin to SSH key expiry notifications)
Could have
- Allow administrators to provide an S/MIME private key for the email address used by their GitLab instance so users can encrypt inbound emails to GitLab (e.g. replies to comments)
- Ensure end users have access to the public key for the email address used by their GitLab instance (e.g. via PKE)
Won't have
- PGP encryption is out of scope for this issue. See #19056 instead.
Open questions
- Should this feature be EE-only?
- Do we need to make administration of S/MIME encryption accessible outside of the Admin Area for SaaS customers?
Implementation guidance
AFAIU, we already have a solid foundation for signing emails thanks to this community contribution: gitlab-foss!30644 (merged) (related docs).
What we currently support is signing outgoing emails with an instance-wide public key that needs to be set in the instance's config file.
So, building upon the existing groundwork, I would weight the remaining work as such, where each step's weight should be added to the previous one's.
Must have => 3
A mix of database, backend and frontend work where we'll need to expose a new user setting as well as an instance-wide setting and update the S/MIME interceptor to leverage the user's key when available.
Should have => 2
Mostly backend work where the S/MIME interceptor could probably be responsible for redacting email contents, and a Sidekiq worker would take care of sending expiry notices.
Could have => 2
Again, more database, backend and frontend work, but I don't foresee major challenges here.
Links / references
Related issues: