On Wed, Nov 13, 2024 at 11:59:39AM +0100, Simona Vetter wrote: > On Wed, 13 Nov 2024 at 11:55, Thorsten Leemhuis <linux@xxxxxxxxxxxxx> 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@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 ? > > > > 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
