From: Simona Vetter <simona.vetter@ffwll.ch>
To: Thorsten Leemhuis <linux@leemhuis.info>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Jonathan Corbet <corbet@lwn.net>,
workflows@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] docs: reminder to not expose potentially private email addresses
Date: Wed, 13 Nov 2024 11:59:39 +0100 [thread overview]
Message-ID: <CAKMK7uGwK0OYu+cVJnUVd5nMZRG8jJBXJUuo0xFXdyrubJFW4g@mail.gmail.com> (raw)
In-Reply-To: <b160f728-b34f-433d-8cc4-677605990936@leemhuis.info>
On Wed, 13 Nov 2024 at 11:55, Thorsten Leemhuis <linux@leemhuis.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@leemhuis.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 ?
>
> Hmmm. Good point, thx for bringing this up. And of course it is. But
> it's the second point in a list and thus should not overrule the first
> one. But I can see that it could be read like that. :-/ Up to some point
> I even was aware of it, as the added "given the above constraints" later
> in that point shows. But I guess I wanted to stay close to the previous
> text and that is not sufficient.
>
> Hmmm. So how about writing the second point like this:
>
> """
> Even if the email address is free to use in tags, it is only appropriate
> to use in Cc: without explicit permission of the person named; using it
> in Reported-by: likewise is often appropriate as well, but ask for
> permission for bugs reported in private.
> """
>
> Hope that "likewise" is sufficient here...
I think these two points are fairly unrelated. The first is about
using the email address, for privacy concerns. The second point is
about adding the tag at all, which you're not allowed to do except for
Cc: tags. Because forging reviewed/acked/tested-by tags is really not
good. Putting the "no tag forgeries" rule under the privacy section is
I think what's confusing here.
-Sima
>
> >> + 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.
> > [...]
>
> Ciao., Thorsten
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2024-11-13 10:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-13 8:35 Thorsten Leemhuis
2024-11-13 10:26 ` Laurent Pinchart
2024-11-13 10:55 ` Thorsten Leemhuis
2024-11-13 10:59 ` Simona Vetter [this message]
2024-11-13 11:36 ` Laurent Pinchart
2024-11-13 13:11 ` Mauro Carvalho Chehab
2024-11-13 13:59 ` Geert Uytterhoeven
2024-11-13 11:40 ` Mauro Carvalho Chehab
2024-11-13 13:43 ` Thorsten Leemhuis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKMK7uGwK0OYu+cVJnUVd5nMZRG8jJBXJUuo0xFXdyrubJFW4g@mail.gmail.com \
--to=simona.vetter@ffwll.ch \
--cc=corbet@lwn.net \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox