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
+   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@vger.kernel.org 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
-- 
2.45.0

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@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 ?

> +   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@vger.kernel.org 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

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

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

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

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

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

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

On 13.11.24 12:40, Mauro Carvalho Chehab wrote:
> Em Wed, 13 Nov 2024 11:59:39 +0100
> Simona Vetter <simona.vetter@ffwll.ch> escreveu:
>> On Wed, 13 Nov 2024 at 11:55, Thorsten Leemhuis <linux@leemhuis.info> wrote:
>>> On 13.11.24 11:26, Laurent Pinchart wrote:  
>>>>> +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.

Thx. I went with a slightly changed variant for now, hope that's okay:

"""
Only specify email addresses if owners explicitly permitted their use or
if the addresses have previously been used publicly for contributions to
the Linux kernel found in the lore archives or the commit history.
"""

Regarding the other points Simona and Laurent brought up: many thx for
that, I will take a closer look soon (I need to check if the suggested
approaches really work; while at it I also want to check if
5.Posting.rst mentions the "no tag forgeries" aspect at all; from a
quick look that seems to be missing, so I might add a patch that puts it
in an appropriate place).

Ciao, Thorsten

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

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

Em Wed, 13 Nov 2024 13:36:50 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> On Wed, Nov 13, 2024 at 11:59:39AM +0100, Simona Vetter wrote:
> > 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.  
> 
> 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 can't imagine that. This is for sure an exceptional case, on which
people should explicitly notify.

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

If someone reports a problem publicly, IMO the right thing to do is
to just add a reported-by to credit who reported the issue, except
if, while doing the report, someone explicitly asks not to do so.
Personally, I never faced such case, though.

Co-developed-by requires explicit ack, perhaps with one exception:
if we receive two or more independent patches with the same diff, which
is common when there is an issue reported by commonly used CIs and
static analyzers, all with their SoBs, I guess it should be ok to
group them into a single patch and use Co-developed-by.

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

I don't like "often" either, but it should be ok in the absense of a
clearer alternative.

Thanks,
Mauro

On Wed, Nov 13, 2024 at 2:20 PM Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
> Em Wed, 13 Nov 2024 13:36:50 +0200
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> > On Wed, Nov 13, 2024 at 11:59:39AM +0100, Simona Vetter wrote:
> > > 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.
> >
> > 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 can't imagine that. This is for sure an exceptional case, on which
> people should explicitly notify.
>
> > 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.
>
> If someone reports a problem publicly, IMO the right thing to do is
> to just add a reported-by to credit who reported the issue, except
> if, while doing the report, someone explicitly asks not to do so.
> Personally, I never faced such case, though.

And nowadays scripts/checkpatch.pl will instruct you to add a
Closes:-tag too.  Perhaps it should recommend to double-check
if no public report is available?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds