Message-ID: <20241113102619.GC29944@pendragon.ideasonboard.com>
Date: Wed, 13 Nov 2024 12:26:19 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Thorsten Leemhuis <linux@...mhuis.info>
Cc: Jonathan Corbet <corbet@....net>, workflows@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] docs: reminder to not expose potentially private
 email addresses

Hi Thorsten,

On Wed, Nov 13, 2024 at 09:35:03AM +0100, Thorsten Leemhuis wrote:
> Remind developers to not expose private email addresses, as some people
> become upset if their addresses end up in the lore archives or the Linux
> git tree.
> 
> While at it, explicitly mention the dangers of our bugzilla instance
> here, as it makes it easy to forget that email addresses visible there
> are only shown to logged-in users.
> 
> These are not a theoretical issues, as one maintainer mentioned that
> his employer received a EU GDPR (general data protection regulation)
> complaint after exposuring a email address used in bugzilla through a
> tag in a patch description.
> 
> Signed-off-by: Thorsten Leemhuis <linux@...mhuis.info>
> ---
> Note: this triggers a few checkpatch.pl complaints that are irrelevant
> when when ti comes to changes like this.
> 
> v1:
> - initial version
> ---
>  Documentation/process/5.Posting.rst          | 17 +++++++++---
>  Documentation/process/submitting-patches.rst | 27 +++++++++++++++++---
>  2 files changed, 36 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
> index b3eff03ea2491c..1f6942948db349 100644
> --- a/Documentation/process/5.Posting.rst
> +++ b/Documentation/process/5.Posting.rst
> @@ -264,10 +264,19 @@ The tags in common use are:
>   - Cc: the named person received a copy of the patch and had the
>     opportunity to comment on it.
>  
> -Be careful in the addition of tags to your patches, as only Cc: is appropriate
> -for addition without the explicit permission of the person named; using
> -Reported-by: is fine most of the time as well, but ask for permission if
> -the bug was reported in private.
> +Note, remember to respect other people's privacy when adding these tags:
> +
> + - Only specify email addresses, if owners explicitly permitted their use or
> +   are fine with exposing them to the public based on previous actions found in
> +   the lore archives. In practice you therefore often will be unable to hastily
> +   specify addresses for users of bug trackers, as those usually do expose the
> +   email addresses at all or only to logged in users. The latter is the case
> +   for bugzilla.kernel.org, whose privacy policy explicitly states that 'your
> +   email address will never be displayed to logged out users'.
> +
> + - Only Cc: is appropriate for addition without the explicit permission of the

Isn't Cc: as problematic as any other tag, is it ends up in both the git
history and the lore archive ?

> +   person named; using Reported-by: is fine most of the time as well given the
> +   above constraints, but ask for permission for bugs reported in private.
>  
>  
>  Sending the patch
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index 1518bd57adab50..3373ba3025d6d8 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -484,7 +484,9 @@ provided such comments, you may optionally add a ``Cc:`` tag to the patch.
>  This is the only tag which might be added without an explicit action by the
>  person it names - but it should indicate that this person was copied on the
>  patch.  This tag documents that potentially interested parties
> -have been included in the discussion.
> +have been included in the discussion. Note, ensure owners of email addresses
> +are fine with exposing their addresses in tags like this; see 'Privacy aspects
> +when using tags...' below for details.
>  
>  Co-developed-by: states that the patch was co-created by multiple developers;
>  it is used to give attribution to co-authors (in addition to the author
> @@ -530,9 +532,10 @@ hopefully inspires them to help us again in the future. The tag is intended for
>  bugs; please do not use it to credit feature requests. The tag should be
>  followed by a Closes: tag pointing to the report, unless the report is not
>  available on the web. The Link: tag can be used instead of Closes: if the patch
> -fixes a part of the issue(s) being reported. Please note that if the bug was
> -reported in private, then ask for permission first before using the Reported-by
> -tag.
> +fixes a part of the issue(s) being reported. Note, ensure owners of email
> +addresses are fine with exposing their addresses in tags like this; see
> +'Privacy aspects when using tags...' below for details. And if the bug was
> +reported in private, ask for permission first before using the Reported-by-tag.
>  
>  A Tested-by: tag indicates that the patch has been successfully tested (in
>  some environment) by the person named.  This tag informs maintainers that
> @@ -600,6 +603,22 @@ process nor the requirement to Cc: stable@...r.kernel.org on all stable
>  patch candidates. For more information, please read
>  Documentation/process/stable-kernel-rules.rst.
>  
> +Privacy aspects when using tags like Cc:, Reported-by:, Tested-by:, ...
> +-----------------------------------------------------------------------
> +
> +Only specify email addresses, if owners explicitly permitted their use or
> +are fine with exposing them to the public based on previous actions found in
> +the lore archives. In practice you therefore often will be unable to blindly
> +specify addresses for users of bug trackers, as those usually do expose the
> +email addresses at all or only to logged in users. The latter is the case
> +for bugzilla.kernel.org, whose privacy policy explicitly states that 'your
> +email address will never be displayed to logged out users'.
> +
> +Furthermore note that only Cc: is appropriate for addition without the
> +explicit permission of the person named; using Reported-by: is fine most of
> +the time as well given the above constraints, but ask for permission for bugs
> +reported in private.
> +
>  .. _the_canonical_patch_format:
>  
>  The canonical patch format
> 
> base-commit: 623e5747c680d3854b6b9882d9907096bc63580d

-- 
Regards,

Laurent Pinchart

Powered by blists - more mailing lists