External recipients feature is leaking content of confidential issues

changed the description

Except, it seems our Gitlab hardening has no effect in that case, as the person I added got the confidential content directly into their inbox.

And, to be clear, it's only that external user that is affected here. That is, even in the case the external user posts an update to a ticket (via mail), everyone else getting notifications from the ticket is benefiting from the Gitlab hardening we did and won't have the contents of that or any other comment of the confidential ticket in their inbox.

what do you mean by "hardening" here? that people don't get the plain text by email?

or, in other words, what's the issue here? that external participants do get the cleartext by email?

external participants are interesting, but that's only for service desk issues, am i right?

what do you mean by "hardening" here? that people don't get the plain text by email?

Yes.

or, in other words, what's the issue here? that external participants do get the cleartext by email?

Yes.

external participants are interesting, but that's only for service desk issues, am i right?

No. I used it for a regular Gitlab ticket as well over in https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/81.

interesting! i didn't realize that thing even existed.

@micah you might want to see this ticket. it seems there's an edge case your GitLab patch for confidential tickets doesn't cover, and it's the new External Participants feature, that allows project owners to add CCs to issues that will get a notification even though they don't have access to the project.

my theory is the header doesn't get added correctly in those cases, so our redaction system doesn't kick in.

@gk could you show us the full headers of an email that should have been redacted but wasn't? normally, there should be a X-GitLab-ConfidentialIssue that our mail server uses to redact the email.

added Needs Information label

added Backlog label and removed Needs Information label

This is cool - the external participant feature wasn't added until Gitlab 17, and true to their documentation being poor, it seemed that it was only available for Service Desk items, and was behind a feature flag. Nice to see that it is actually working, this will be useful for confidential tickets.

Regarding the leaking of confidential contents, there isn't too much we can do here. The confidential issue system will add a header to the outgoing email, and it is up to the MDA to redact the body of the message. If this header was added to the external participant's email (we do not know yet, until we can see the header), then our MDA redacting it would result in a useless situation for the external contributor. They would receive the confidential issue email and a link to the issue, and as far as I understand it external participants are not able to view the issue via the link, they are only able to receive updates and send replies, but aren't able to load the issue and see the entire discussion. So if they got a redacted body, and a link, they would be unable to do anything at all with that.

I think we need to simply be aware that if we are going to loop in someone externally, we do not have any control over the contents of the confidential communications from a email snooping level.

[...]

I think we need to simply be aware that if we are going to loop in someone externally, we do not have any control over the contents of the confidential communications from a email snooping level.

So, in other words, this is already working exactly as designed and we want external recipients to receive clear text?

I don't mind, i just want to make sure I understand what we end up with here.

If that's the case, the next step here is probably to document this in the wiki page and close this issue.

...

On 2024-10-16 12:29:16, micah (@micah) wrote:

I think we need to simply be aware that if we are going to loop in someone externally, we do not have any control over the contents of the confidential communications from a email snooping level.

So, in other words, this is already working exactly as designed and we want external recipients to receive clear text?

I'm not sure I would say 'exactly as designed and we want external recipients to receive clear text'. This external contributors thing was added later, and wasn't even considered as something when the confidential issue patch was created.

In an ideal world, we would have a way to have confidential issue recipients (external or otherwise) receive encrypted text that they only they can decrypt. We do not have that option at this point.

If we want to loop in external contributors, with the current setup, we either have to get them an account, with the right permissions to view the confidential issue, or we have to use this mechanism where they get unencrypted emails. The tradeoffs here must be weighed carefully.

If the second one is used, and confidential issue patch were changed to redact the emails for those external contributors, then there is no point in adding them as external contributors as they would just receive useless emails without any ability to view the contents of the ticket.

If that's the case, the next step here is probably to document this in the wiki page and close this issue.

I'm still interested to know if the external contributor receives the header. I've added an external email to a confidential ticket (https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/81) to see what happens myself.

...

On 2024-10-16 12:45:34, anarcat (@anarcat) wrote:

Adding myself to an issue produces this 'welcome email':

You have been added to ticket #81.

Reply to this email to participate in the discussion. All other participants of the ticket will receive notifications of your reply.

You can unsubscribe from further updates to this ticket. To receive updates in the future, you will have to be added again as a participant.

At the bottom is an unsubscribe link that I am not including.

This email has no confidentiality header, not that I'd expect one.

FWIW, the header for external contributors does not include the Confidentiality flag:

Return-Path: <git@gitlab.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on towhee.riseup.net
X-Spam-Level: 
X-Spam-Pyzor: 
X-Spam-Status: No, score=-5.0 required=4.0 shortcircuit=ham autolearn=disabled
	version=3.4.6
X-Spam-Report: 
	* -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited
	*      rule
	* -5.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
Delivered-To: micah@riseup.net
Received: from mx1.riseup.net (mx1-pn.riseup.net [10.0.1.33])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by towhee.riseup.net (Postfix) with ESMTPS id 4XTBcB31sQz4J
	for <micah@riseup.net>; Wed, 16 Oct 2024 13:28:10 +0000 (UTC)
Received: from gitlab-02.torproject.org (gitlab-02.torproject.org [116.202.120.180])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mx1.riseup.net (Postfix) with ESMTPS id 4XTBcB0nKZzDqmT
	for <micah@riseup.net>; Wed, 16 Oct 2024 13:28:10 +0000 (UTC)
Authentication-Results: mx1.riseup.net;
	dkim=pass (2048-bit key; secure) header.d=gitlab.torproject.org header.i=@gitlab.torproject.org header.a=rsa-sha256 header.s=2022-gitlab-02 header.b=Ncb1L83K;
	dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gitlab.torproject.org;
	s=2022-gitlab-02; t=1729085288;
	bh=awXWLYXyE5Abxt6HB41mh9DWsk+OIjS/BS65fSOS6Qo=;
	h=Date:From:Reply-To:To:In-Reply-To:References:Subject:List-Id:
	 List-Unsubscribe:From;
	b=Ncb1L83KE8ANZoPBGgk1VDRtAIL1M7p+f4fnyvSJtKIsG/LqZWm2PU8mNpehdMJcd
	 KMVMfuyWsiZP8BCmuEi5gsaQPtxuzg7o+VxMIchNU5Ypf1enxQ+4VYuje/204p7OUN
	 NwTaYFTG5VwR7T4dlqBRf/xhm3IMnWEbb4d2ykB6VDRpRP4WbLSXM+bIVrTEyCg4R3
	 4KCFF57h0tU9gcMsA2Bzms6pPn6m/2Hr8SFrQ1W5QyhqFBvKoyBxP5+sd0qscyx9z/
	 +hNgvW6f5R3NSHM6W2qKG4/Pxesrd6fgsK9kL1+MrdDI7CyKDUIunyRQw9BTyv3PMi
	 OOsXmbrTBW47A==
Received: by gitlab-02.torproject.org (Postfix, from userid 995)
	id B9CAC18070A; Wed, 16 Oct 2024 13:28:08 +0000 (UTC)
Date: Wed, 16 Oct 2024 13:28:08 +0000
From: "micah (@micah)" <git@gitlab.torproject.org>
Reply-To: The Tor Project / Network Health / Analysis <git+728f72de9586299418b2c1d35c4f1fca@gitlab.torproject.org>
To: micah@riseup.net
Message-ID: <1a765978bef25f0af9ea015c629c2031@gitlab.torproject.org>
In-Reply-To: <issue_328603@gitlab.torproject.org>
References: <reply-728f72de9586299418b2c1d35c4f1fca@gitlab.torproject.org>
 <issue_328603@gitlab.torproject.org>
Subject: Re: Way more bytes per second read than written on some relays (#81)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_670fbf68a9701_24dbf47a0a81267783";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
X-GitLab-Project: Analysis
X-GitLab-Project-Id: 1407
X-GitLab-Project-Path: tpo/network-health/analysis
List-Id: tpo/network-health/analysis
 <1407.analysis.network-health.tpo.gitlab.torproject.org>
List-Unsubscribe: <https://gitlab.torproject.org/-/sent_notifications/REDACTED/unsubscribe?force=true>,<mailto:git+728f72de9586299418b2c1d35c4f1fca-unsubscribe@gitlab.torproject.org>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
X-GitLab-Issue-ID: 328603
X-GitLab-Issue-IID: 81
X-GitLab-Issue-State: opened
X-GitLab-Reply-Key: 728f72de9586299418b2c1d35c4f1fca
Auto-Submitted: auto-generated
X-Auto-Response-Suppress: All

In an ideal world, we would have a way to have confidential issue recipients (external or otherwise) receive encrypted text that they only they can decrypt. We do not have that option at this point.

Just to put it out there, we do have an issue open about doing such encryption (#151), but even the basic implementation suggested there assumes a lot that doesn't cover for this specific use case. Namely, it assumes the recipient has a gitlab account and that is used to discover the public key, which is obviously not the case here. To cover for this use case, we'd need to do key discovery, and that's a rather dangerous proposition in the modern, hostile OpenPGP world...

marked this issue as related to #151

I'd be open to close this issue

Me too.

assigned to @anarcat

okay, i'll update docs and close then

added Documentation Next labels and removed Backlog label

added Doing label and removed Next label

closed

External recipients feature is leaking content of confidential issues

Child items ...

Activity