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: <20241113113650.GA31681@pendragon.ideasonboard.com>
Date: Wed, 13 Nov 2024 13:36:50 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Simona Vetter <simona.vetter@...ll.ch>
Cc: Thorsten Leemhuis <linux@...mhuis.info>,
	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

On Wed, Nov 13, 2024 at 11:59:39AM +0100, Simona Vetter wrote:
> 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. 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.

Reviewed-by, Acked-by, Tested-by or Signed-off-by clearly must never be
forged, and that's indeed unrelated to privacy. Separating the privacy
concerns and the no-forgery concerns sounds like it would make the
document clearer.

It's not just tag forgery though. I can imagine that some people would
be fine with their e-mail address appearing in lore, but wouldn't when
to be listed in any tag in the git history. I try to ask permission
before adding a Reported-by or Co-developed-by tag, even if the person
has participated in public discussions on mailing lists. Should we
generalize asking for permission ? The alternative of saying that
Reported-by can "often" be added without explicit permission doesn't
seem very clear to me.

> > >> +   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

-- 
Regards,

Laurent Pinchart

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ