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.
**Table of Contents**
- Announcement
- Affected users
- Future work
- OpenPGP certificates in GitLab
- OpenPGP signatures
- Background
- History of the confidential issue handling
- TPA handling of OpenPGP certificates
- OpenPGP implementation details
# 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][].
[usual support channels]:
https://gitlab.torproject.org/tpo/tpa/team/-/wikis/support
[file an issue]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/new
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][].
[discussion issue]: https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/151
## 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.
[actually discouraged]:
https://www.ietf.org/archive/id/draft-ietf-lamps-e2e-mail-guidance-17.html#name-avoid-offering-encrypted-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.
[gitlab-org/gitlab#19056]: https://gitlab.com/gitlab-org/gitlab/-/issues/19056
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.
[tpo/tpa/gitlab#23]: https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/23
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.
[fireworks]:
https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/23#note_2951630
## 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.
[tpo/tpa/team#29671]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/29671
We are also aware that the keyring is severely out of date and
[requires a serious audit][].
[requires a serious audit]:
https://gitlab.torproject.org/tpo/tpa/team/-/issues/31214
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.
[Stateless OpenPGP]: https://dkg.gitlab.io/openpgp-stateless-cli/
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.
[PETA]:
https://en.wikipedia.org/wiki/People_for_the_Ethical_Treatment_of_Animals
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.
[fabric-tasks]: https://gitlab.torproject.org/tpo/tpa/fabric-tasks/
[merge request !40]:
https://gitlab.torproject.org/tpo/tpa/fabric-tasks/-/merge_requests/40
Follow the progress on this work in the [discussion issue][].
--
Antoine Beaupré
torproject.org system administration
signature.asc
Description: PGP signature
_______________________________________________ tor-project mailing list -- tor-project@lists.torproject.org To unsubscribe send an email to tor-project-le...@lists.torproject.org
