linux-kernel - Re: [PATCH v1] docs: reminder to not expose potentially private email addresses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241113124010.7e7edaa1@foz.lan>
Date: Wed, 13 Nov 2024 12:40:10 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Simona Vetter <simona.vetter@...ll.ch>
Cc: Thorsten Leemhuis <linux@...mhuis.info>, Laurent Pinchart
 <laurent.pinchart@...asonboard.com>, 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

Em Wed, 13 Nov 2024 11:59:39 +0100
Simona Vetter <simona.vetter@...ll.ch> escreveu:

> On Wed, 13 Nov 2024 at 11:55, Thorsten Leemhuis <linux@...mhuis.info> wrote:
> >
> > On 13.11.24 11:26, Laurent Pinchart wrote:  
> > > 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. 

There is no comma between "addresses" and "if".

"previous actions" sounds a little to vague. Also, the text doesn't cover
everything, as lore archives may contain gaps.  I would, instead be clear:

	 - Only specify email addresses if owners explicitly permitted their use or
	   if such e-mail was previously used publicly for Linux contributions, which
	   can be checked by looking at the lore archives and at the git log. 

I added "git log there" because, in practice, nobody has the time to double-check
what e-mails are public: developers rely that scripts/checkpatch.pl will
check git log when creating the Cc: list.

Thanks,
Mauro