title: TPA-RFC-80: GitLab confidential notifications encryption status: standard discussion: https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/151
Summary: GitLab now encrypts outgoing email notifications on confidential issues, if your key is in LDAP, OpenPGP keys stored in GitLab will be used soon.
[[TOC]]
Announcement
Anyone who has dealt with GitLab confidential issues will know this message:
A comment was added to a confidential issue and its content was redacted from this email notification.
If you found that irritating, you're not alone! Rejoice, its time is coming to an end.
Starting today (around 2025-06-10 19:00UTC), we have deployed a new encryption system in the GitLab notification pipeline. If your OpenPGP certificate (or "PGP key") is properly setup in LDAP, you will instead receive a OpenPGP-encrypted email with the actual contents.
No need to click through anymore!
If your key is not available, nothing changes: you will still get the "redacted" messages. If you do not control your key, yet it's still valid and in the keyring, you will get encrypted email you won't be able to read.
In any case, if any of those new changes cause any problems or if you need to send us an OpenPGP certificate (or update it), file an issue or reach out to our usual support channels.
We also welcome constructive feedback on the implementation, relieved thanks and other comments, either here, through the above support channels, or in the discussion issue.
Affected users
Any GitLab user subscribed to confidential issues and who is interested in not getting "redacted" emails from GitLab.
Future work
OpenPGP certificates in GitLab
Right now, only "LDAP keys" (technically, the OpenPGP certificates
account-keyring.git project) are considered for encryption.
Only mail delivered to @torproject.org are considered as well.
In the future, we hope to implement a GitLab API lookup that will allow other users to upload OpenPGP certificates through GitLab to use OpenPGP encryption for outgoing mail.
This has not been implemented yet because implementing the current backend was vastly easier, but we still hope to implement the GitLab backend.
OpenPGP signatures
Mails are currently encrypted, without signature, which is actually discouraged. We are considering signing outgoing mail, but this needs to be done carefully because we must handle yet another secret, rotation, expiry and so on.
This means, among other things, that the OpenPGP messages do not provide any sort of authentication that the message really comes from GitLab. It's still entirely possible for an attacker to introduce "fake" GitLab notifications through this system, so you should still consider notifications to be advisory. The source of truth here is the GitLab web interface.
OpenPGP signatures were seen as not absolutely necessary for a first implementation of the encryption system, but may be considered in the future. Note that we do not plan on implementing signatures for all outgoing mail at the time.
Background
History of the confidential issue handling
GitLab supports "confidential issues" that are accessible only to the issue creator and users with the "reporter" role on a project. It is used to manage security-sensitive issues and any issue that contains privately identifiable information (PII).
When someone creates or modifies an issue on GitLab, it sends a notification to users watching the issue. Unfortunately, those notifications are sent by email without any sort of protection. This is a long-standing issue in GitLab (e.g. gitlab-org/gitlab#19056, 2017) that doesn't seem to have gotten any interest upstream.
We realized this problem shortly after the GitLab migration, in 2020 (tpo/tpa/gitlab#23), at which time it wasn't clear what we could do about it.
But a few years later (September 2022), Micah actually bit the bullet and started work on patching GitLab itself to at least identify confidential issues with a special header.
He also provided a prototype filtering script that would redact (but not encrypt!) messages on the way out, which anarcat improved on and deployed in production. That was deployed in October 2023 and there were actual fireworks to celebrate this monumental change, which has been working reliably for almost two years at this point.
TPA handling of OpenPGP certificates
We acknowledge our handling of OpenPGP keys (or "certificates") is far from optimal. Key updates require manual work and the whole thing is pretty arcane and weird, even weirder than what OpenPGP actually is, if that's even possible. We have an issue to address that technical debt (tpo/tpa/team#29671) and we're considering this system to be legacy.
We are also aware that the keyring is severely out of date and requires a serious audit.
The hope, at the moment, is we can ignore that problem and rely on the GitLab API for users to provide key updates for this system, with the legacy keyring only used as a fallback.
OpenPGP implementation details
Programmers might be interested to know this was implemented in an existing Python script, by encrypting mail with a SOP interface (Stateless OpenPGP), which simplified OpenPGP operations tremendously.
While SOP is not yet an adopted standards and implementations are completely solid yet, it has provided a refreshing experience in OpenPGP interoperability that actually shows great promise in the standard and its future.
PGP/MIME is another story altogether: that's still an horrible mess that required crafting MIME parts by hammering butterflies into melting anvils with deprecated Python blood. But that's just a normal day at the TPA office, don't worry, everything was PETA approved.
The implementation is available in TPA's fabric-tasks repository, currently as merge request !40 but will be merged into the main branch once GitLab API support is implemented.
Follow the progress on this work in the discussion issue.