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@xxxxxxxxxxxxx> > --- > 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@xxxxxxxxxxxxxxx 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
