Point out that explicit permission is usually needed to tag other people
in changes, but mention that implicit permission can be sufficient in
certain cases. This fixes slight inconsistencies between Reported-by:
and Suggested-by: and makes the usage more intuitive.

While at it, explicitly mention the dangers of our bugzilla instance, as
it makes it easy to forget that email addresses visible there are only
shown to logged-in users.

The latter is not a theoretical issue, as one maintainer mentioned that
his employer received a EU GDPR (general data protection regulation)
complaint after exposing a email address used in bugzilla through a tag
in a patch description.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Simona Vetter <simona.vetter@ffwll.ch>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
Note: this triggers a few checkpatch.pl complaints that are irrelevant
when when to comes to changes like this.

v2:
- Retry differently. This slightly hardens the rule for Reported-by:
  while slightly lessening it for Suggested-by:. Those in the end are
  quite similar, so it does not make much sense to apply different ones.
  I considered using an approach along the lines of "if you reported it
  in pubic by mail, implicit permission to use in a tag is granted"; but
  I abstained from it, as I assume there are good reasons for the
  existing approach regarding Suggested-by:.
- CC all the people that provided feedback on the text changes in v1

v1: https://lore.kernel.org/all/f5bc0639a20d6fac68062466d5e3dd0519588d08.1731486825.git.linux@leemhuis.info/
- initial version
---
 Documentation/process/5.Posting.rst          | 17 ++++++--
 Documentation/process/submitting-patches.rst | 44 ++++++++++++++------
 2 files changed, 45 insertions(+), 16 deletions(-)

diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
index dbb763a8de901d..b45c4f6d65ca95 100644
--- a/Documentation/process/5.Posting.rst
+++ b/Documentation/process/5.Posting.rst
@@ -268,10 +268,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.
+Be careful in the addition of tags to your patches, as nearly all of them need
+explicit permission of the person named.
+
+The only exceptions are Cc:, Reported-by:, and Suggested-by:, as for them
+implicit permission is sufficient under the following circumstances: when the
+person named according to the lore archives or the commit history regularly
+contributes to the Linux kernel using that name and email address -- and in
+case of Reported-by: and Suggested-by: did the reporting or suggestion in
+public. For all other situations explicit permission is required to among
+others prevent exposing email addresses considered private. Especially ask for
+permission when it comes to bug trackers, as most only show addresses to logged
+in users; that includes bugzilla.kernel.org, whose privacy policy explicitly
+states that 'your email address will never be displayed to logged out users'.
 
 
 Sending the patch
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 1518bd57adab50..92b2dc6ae7304a 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -481,10 +481,10 @@ list archives.
 
 If a person has had the opportunity to comment on a patch, but has not
 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.
+This tag documents that potentially interested parties have been included in
+the discussion. Note, this is one of only three tags you might be able to use
+without explicit permission of the person named (see 'Tagging people requires
+permission 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 +530,9 @@ 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, the Reported-by tag is one
+of only three tags you might be able to use without explicit permission of the
+person named (see 'Tagging people requires permission' below for details).
 
 A Tested-by: tag indicates that the patch has been successfully tested (in
 some environment) by the person named.  This tag informs maintainers that
@@ -582,11 +582,11 @@ Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned
 in the patch changelog (after the '---' separator).
 
 A Suggested-by: tag indicates that the patch idea is suggested by the person
-named and ensures credit to the person for the idea. Please note that this
-tag should not be added without the reporter's permission, especially if the
-idea was not posted in a public forum. That said, if we diligently credit our
-idea reporters, they will, hopefully, be inspired to help us again in the
-future.
+named and ensures credit to the person for the idea: if we diligently credit
+our idea reporters, they will, hopefully, be inspired to help us again in the
+future. Note, this is one of only three tags you might be able to use without
+explicit permission of the person named (see 'Tagging people requires
+permission' below for details).
 
 A Fixes: tag indicates that the patch fixes an issue in a previous commit. It
 is used to make it easy to determine where a bug originated, which can help
@@ -600,6 +600,26 @@ 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.
 
+.. _tagging_people:
+
+Tagging people requires permission
+----------------------------------
+
+Be careful in the addition of tags to your patches, as nearly all of them need
+explicit permission of the person named.
+
+The only exceptions are Cc:, Reported-by:, and Suggested-by:, as for them
+implicit permission is sufficient under the following circumstances: when the
+person named according to the lore archives or the commit history regularly
+contributes to the Linux kernel using that name and email address -- and in
+case of Reported-by: and Suggested-by: did the reporting or suggestion in
+public. For all other situations explicit permission is required to among
+others prevent exposing email addresses considered private. Especially ask for
+permission when it comes to bug trackers, as most only show addresses to logged
+in users; that includes bugzilla.kernel.org, whose privacy policy explicitly
+states that 'your email address will never be displayed to logged out users'.
+
+
 .. _the_canonical_patch_format:
 
 The canonical patch format
-- 
2.45.0

Hi Thorsten,

On Sat, Nov 16, 2024 at 10:39 AM Thorsten Leemhuis <linux@leemhuis.info> wrote:
> The latter is not a theoretical issue, as one maintainer mentioned that
> his employer received a EU GDPR (general data protection regulation)
> complaint after exposing a email address used in bugzilla through a tag
> in a patch description.

And once it's upstream there is not much we can do about that anymore,
right?

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

On 16.11.24 12:38, Geert Uytterhoeven wrote:
> On Sat, Nov 16, 2024 at 10:39 AM Thorsten Leemhuis <linux@leemhuis.info> wrote:
>> The latter is not a theoretical issue, as one maintainer mentioned that
>> his employer received a EU GDPR (general data protection regulation)
>> complaint after exposing a email address used in bugzilla through a tag
>> in a patch description.
> 
> And once it's upstream there is not much we can do about that anymore,
> right?

Well, right. :-D I thought that was obvious, so I did not mentioned it
in the patch description. I considered mentioning it in the added text,
but in the end decided against it, as once an email address is exposed
in a patch posting it's kind of too late anyway, as it then ended up in
external archives we have no control over.

Ciao, Thorsten

On Sat, Nov 16, 2024 at 10:33:59AM +0100, Thorsten Leemhuis wrote:
> Point out that explicit permission is usually needed to tag other people
> in changes, but mention that implicit permission can be sufficient in
> certain cases. This fixes slight inconsistencies between Reported-by:
> and Suggested-by: and makes the usage more intuitive.
> 
> While at it, explicitly mention the dangers of our bugzilla instance, as
> it makes it easy to forget that email addresses visible there are only
> shown to logged-in users.
> 
> The latter is not a theoretical issue, as one maintainer mentioned that
> his employer received a EU GDPR (general data protection regulation)
> complaint after exposing a email address used in bugzilla through a tag
> in a patch description.
> 
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Simona Vetter <simona.vetter@ffwll.ch>
> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
> ---
> Note: this triggers a few checkpatch.pl complaints that are irrelevant
> when when to comes to changes like this.
> 
> v2:
> - Retry differently. This slightly hardens the rule for Reported-by:
>   while slightly lessening it for Suggested-by:. Those in the end are
>   quite similar, so it does not make much sense to apply different ones.
>   I considered using an approach along the lines of "if you reported it
>   in pubic by mail, implicit permission to use in a tag is granted"; but
>   I abstained from it, as I assume there are good reasons for the
>   existing approach regarding Suggested-by:.
> - CC all the people that provided feedback on the text changes in v1
> 
> v1: https://lore.kernel.org/all/f5bc0639a20d6fac68062466d5e3dd0519588d08.1731486825.git.linux@leemhuis.info/
> - initial version
> ---
>  Documentation/process/5.Posting.rst          | 17 ++++++--
>  Documentation/process/submitting-patches.rst | 44 ++++++++++++++------
>  2 files changed, 45 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
> index dbb763a8de901d..b45c4f6d65ca95 100644
> --- a/Documentation/process/5.Posting.rst
> +++ b/Documentation/process/5.Posting.rst
> @@ -268,10 +268,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.
> +Be careful in the addition of tags to your patches, as nearly all of them need
> +explicit permission of the person named.
> +
> +The only exceptions are Cc:, Reported-by:, and Suggested-by:, as for them

I don't understand what you mean by "only exceptions" here.  Exceptions
to what?

> +implicit permission is sufficient under the following circumstances: when the
> +person named according to the lore archives or the commit history regularly
> +contributes to the Linux kernel using that name and email address -- and in
> +case of Reported-by: and Suggested-by: did the reporting or suggestion in
> +public. For all other situations explicit permission is required to among
> +others prevent exposing email addresses considered private. Especially ask for
> +permission when it comes to bug trackers, as most only show addresses to logged
> +in users; that includes bugzilla.kernel.org, whose privacy policy explicitly
> +states that 'your email address will never be displayed to logged out users'.

How about makeing this much simpler, basically "any public reference can
be used, but please note, email addresses in bugzilla.kernel.org are not
public.  Anything offered in private should probably not be referenced."
or something like that?

thanks,

greg k-h

Em Sat, 16 Nov 2024 11:42:06 +0100
Greg KH <gregkh@linuxfoundation.org> escreveu:

> On Sat, Nov 16, 2024 at 10:33:59AM +0100, Thorsten Leemhuis wrote:
> > Point out that explicit permission is usually needed to tag other people
> > in changes, but mention that implicit permission can be sufficient in
> > certain cases. This fixes slight inconsistencies between Reported-by:
> > and Suggested-by: and makes the usage more intuitive.
> > 
> > While at it, explicitly mention the dangers of our bugzilla instance, as
> > it makes it easy to forget that email addresses visible there are only
> > shown to logged-in users.
> > 
> > The latter is not a theoretical issue, as one maintainer mentioned that
> > his employer received a EU GDPR (general data protection regulation)
> > complaint after exposing a email address used in bugzilla through a tag
> > in a patch description.
> > 
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Cc: Simona Vetter <simona.vetter@ffwll.ch>
> > Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
> > ---
> > Note: this triggers a few checkpatch.pl complaints that are irrelevant
> > when when to comes to changes like this.
> > 
> > v2:
> > - Retry differently. This slightly hardens the rule for Reported-by:
> >   while slightly lessening it for Suggested-by:. Those in the end are
> >   quite similar, so it does not make much sense to apply different ones.
> >   I considered using an approach along the lines of "if you reported it
> >   in pubic by mail, implicit permission to use in a tag is granted"; but
> >   I abstained from it, as I assume there are good reasons for the
> >   existing approach regarding Suggested-by:.
> > - CC all the people that provided feedback on the text changes in v1
> > 
> > v1: https://lore.kernel.org/all/f5bc0639a20d6fac68062466d5e3dd0519588d08.1731486825.git.linux@leemhuis.info/
> > - initial version
> > ---
> >  Documentation/process/5.Posting.rst          | 17 ++++++--
> >  Documentation/process/submitting-patches.rst | 44 ++++++++++++++------
> >  2 files changed, 45 insertions(+), 16 deletions(-)
> > 
> > diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
> > index dbb763a8de901d..b45c4f6d65ca95 100644
> > --- a/Documentation/process/5.Posting.rst
> > +++ b/Documentation/process/5.Posting.rst
> > @@ -268,10 +268,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.
> > +Be careful in the addition of tags to your patches, as nearly all of them need
> > +explicit permission of the person named.
> > +
> > +The only exceptions are Cc:, Reported-by:, and Suggested-by:, as for them  
> 
> I don't understand what you mean by "only exceptions" here.  Exceptions
> to what?
> 
> > +implicit permission is sufficient under the following circumstances: when the
> > +person named according to the lore archives or the commit history regularly
> > +contributes to the Linux kernel using that name and email address -- 

Note that get_maintainer.pl doesn't use a concept of "regularly", and it
doesn't really matter if one has just one or dozens of patches, once it 
has a patch merged with his address, it is now public, as git log will
keep it forever.

Also, if a patch authored by "John Doe <john@doe>" causes a regression, 
a patch fixing the regression should be Cc: to him, even it it was his
first contribution.

So, having a single patch accepted is enough to have other patches
with meta-tag pointing to a name/email.

So, this would be better:

	... or the git commit history contains that name and email address

> > and in
> > +case of Reported-by: and Suggested-by: did the reporting or suggestion in
> > +public. For all other situations explicit permission is required to among
> > +others prevent exposing email addresses considered private. Especially ask for
> > +permission when it comes to bug trackers, as most only show addresses to logged
> > +in users; that includes bugzilla.kernel.org, whose privacy policy explicitly
> > +states that 'your email address will never be displayed to logged out users'.
> 
> How about makeing this much simpler, basically "any public reference can
> be used, but please note, email addresses in bugzilla.kernel.org are not
> public.  Anything offered in private should probably not be referenced."

This works too.

> or something like that?
> 
> thanks,
> 
> greg k-h
> 



Thanks,
Mauro

On 16.11.24 12:50, Mauro Carvalho Chehab wrote:
> Em Sat, 16 Nov 2024 11:42:06 +0100
> Greg KH <gregkh@linuxfoundation.org> escreveu:
>> On Sat, Nov 16, 2024 at 10:33:59AM +0100, Thorsten Leemhuis wrote:
>>> Point out that explicit permission is usually needed to tag other people
>>> in changes, but mention that implicit permission can be sufficient in
>>> certain cases. This fixes slight inconsistencies between Reported-by:
>>> and Suggested-by: and makes the usage more intuitive.
>>>
>>> While at it, explicitly mention the dangers of our bugzilla instance, as
>>> it makes it easy to forget that email addresses visible there are only
>>> shown to logged-in users.
>>>
>>> The latter is not a theoretical issue, as one maintainer mentioned that
>>> his employer received a EU GDPR (general data protection regulation)
>>> complaint after exposing a email address used in bugzilla through a tag
>>> in a patch description.
>>>
>>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>> Cc: Simona Vetter <simona.vetter@ffwll.ch>
>>> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>>> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
>>> ---
>>> Note: this triggers a few checkpatch.pl complaints that are irrelevant
>>> when when to comes to changes like this.
>>>
>>> v2:
>>> - Retry differently. This slightly hardens the rule for Reported-by:
>>>   while slightly lessening it for Suggested-by:. Those in the end are
>>>   quite similar, so it does not make much sense to apply different ones.
>>>   I considered using an approach along the lines of "if you reported it
>>>   in pubic by mail, implicit permission to use in a tag is granted"; but
>>>   I abstained from it, as I assume there are good reasons for the
>>>   existing approach regarding Suggested-by:.
>>> - CC all the people that provided feedback on the text changes in v1
>>>
>>> v1: https://lore.kernel.org/all/f5bc0639a20d6fac68062466d5e3dd0519588d08.1731486825.git.linux@leemhuis.info/
>>> - initial version
>>> ---
>>>  Documentation/process/5.Posting.rst          | 17 ++++++--
>>>  Documentation/process/submitting-patches.rst | 44 ++++++++++++++------
>>>  2 files changed, 45 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
>>> index dbb763a8de901d..b45c4f6d65ca95 100644
>>> --- a/Documentation/process/5.Posting.rst
>>> +++ b/Documentation/process/5.Posting.rst
>>> @@ -268,10 +268,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.
>>> +Be careful in the addition of tags to your patches, as nearly all of them need
>>> +explicit permission of the person named.
>>> +
>>> +The only exceptions are Cc:, Reported-by:, and Suggested-by:, as for them  
>>
>> I don't understand what you mean by "only exceptions" here.  Exceptions
>> to what?
>>
>>> +implicit permission is sufficient under the following circumstances: when the
>>> +person named according to the lore archives or the commit history regularly
>>> +contributes to the Linux kernel using that name and email address -- 
> 
> Note that get_maintainer.pl doesn't use a concept of "regularly", and it
> doesn't really matter if one has just one or dozens of patches, once it 
> has a patch merged with his address, it is now public, as git log will
> keep it forever.
> 
> Also, if a patch authored by "John Doe <john@doe>" causes a regression, 
> a patch fixing the regression should be Cc: to him, even it it was his
> first contribution.
> 
> So, having a single patch accepted is enough to have other patches
> with meta-tag pointing to a name/email.
> 
> So, this would be better:
> 
> 	... or the git commit history contains that name and email address

Good point. But we are getting closer and closer to areas where I feel
out of my league as IANAL without any backing from company lawyers if
this leads to problems down the road.

To still feel comfortable, I would change this to something like:
"""
... or a commit with a 'Signed-off-by' tag containing that name and
email address.
"""

Because one accidental expose of a name and email address (say in a CC:
tag) by a some other developer should not be enough to allow other
developers to expose it again. Highly unlikely corner case, yes, but I
feel better that way. And in the end it should not make much of a
difference.

Ciao, Thorsten

Em Sat, 16 Nov 2024 13:27:44 +0100
Thorsten Leemhuis <linux@leemhuis.info> escreveu:

> On 16.11.24 12:50, Mauro Carvalho Chehab wrote:
> > Em Sat, 16 Nov 2024 11:42:06 +0100
> > Greg KH <gregkh@linuxfoundation.org> escreveu:  
> >> On Sat, Nov 16, 2024 at 10:33:59AM +0100, Thorsten Leemhuis wrote:  
> >>> Point out that explicit permission is usually needed to tag other people
> >>> in changes, but mention that implicit permission can be sufficient in
> >>> certain cases. This fixes slight inconsistencies between Reported-by:
> >>> and Suggested-by: and makes the usage more intuitive.
> >>>
> >>> While at it, explicitly mention the dangers of our bugzilla instance, as
> >>> it makes it easy to forget that email addresses visible there are only
> >>> shown to logged-in users.
> >>>
> >>> The latter is not a theoretical issue, as one maintainer mentioned that
> >>> his employer received a EU GDPR (general data protection regulation)
> >>> complaint after exposing a email address used in bugzilla through a tag
> >>> in a patch description.
> >>>
> >>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >>> Cc: Simona Vetter <simona.vetter@ffwll.ch>
> >>> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> >>> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
> >>> ---
> >>> Note: this triggers a few checkpatch.pl complaints that are irrelevant
> >>> when when to comes to changes like this.
> >>>
> >>> v2:
> >>> - Retry differently. This slightly hardens the rule for Reported-by:
> >>>   while slightly lessening it for Suggested-by:. Those in the end are
> >>>   quite similar, so it does not make much sense to apply different ones.
> >>>   I considered using an approach along the lines of "if you reported it
> >>>   in pubic by mail, implicit permission to use in a tag is granted"; but
> >>>   I abstained from it, as I assume there are good reasons for the
> >>>   existing approach regarding Suggested-by:.
> >>> - CC all the people that provided feedback on the text changes in v1
> >>>
> >>> v1: https://lore.kernel.org/all/f5bc0639a20d6fac68062466d5e3dd0519588d08.1731486825.git.linux@leemhuis.info/
> >>> - initial version
> >>> ---
> >>>  Documentation/process/5.Posting.rst          | 17 ++++++--
> >>>  Documentation/process/submitting-patches.rst | 44 ++++++++++++++------
> >>>  2 files changed, 45 insertions(+), 16 deletions(-)
> >>>
> >>> diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
> >>> index dbb763a8de901d..b45c4f6d65ca95 100644
> >>> --- a/Documentation/process/5.Posting.rst
> >>> +++ b/Documentation/process/5.Posting.rst
> >>> @@ -268,10 +268,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.
> >>> +Be careful in the addition of tags to your patches, as nearly all of them need
> >>> +explicit permission of the person named.
> >>> +
> >>> +The only exceptions are Cc:, Reported-by:, and Suggested-by:, as for them    
> >>
> >> I don't understand what you mean by "only exceptions" here.  Exceptions
> >> to what?
> >>  
> >>> +implicit permission is sufficient under the following circumstances: when the
> >>> +person named according to the lore archives or the commit history regularly
> >>> +contributes to the Linux kernel using that name and email address --   
> > 
> > Note that get_maintainer.pl doesn't use a concept of "regularly", and it
> > doesn't really matter if one has just one or dozens of patches, once it 
> > has a patch merged with his address, it is now public, as git log will
> > keep it forever.
> > 
> > Also, if a patch authored by "John Doe <john@doe>" causes a regression, 
> > a patch fixing the regression should be Cc: to him, even it it was his
> > first contribution.
> > 
> > So, having a single patch accepted is enough to have other patches
> > with meta-tag pointing to a name/email.
> > 
> > So, this would be better:
> > 
> > 	... or the git commit history contains that name and email address  
> 
> Good point. But we are getting closer and closer to areas where I feel
> out of my league as IANAL without any backing from company lawyers if
> this leads to problems down the road.
> 
> To still feel comfortable, I would change this to something like:
> """
> ... or a commit with a 'Signed-off-by' tag containing that name and
> email address.
> """

You should also cover commit authorship, as SOB e-mail might be
different. Currently, -next catches it as warnings, but still
there are cases where maintainer might opt to keep as is, for
instance when the SOB has name+company@e.mail and the author
may have just name@e.mail - or vice-versa.

What about:

"""
commit with a 'Signed-off-by' tag or patch(es) authored or committed by 
that name and email address.
"""

> Because one accidental expose of a name and email address (say in a CC:
> tag) by a some other developer should not be enough to allow other
> developers to expose it again. Highly unlikely corner case, yes, but I
> feel better that way. And in the end it should not make much of a
> difference.

IANAL either, but, once someone else exposes a secret publicly, it is
not a secret anymore. You can't be blamed to mention a previously
"secret email" that was now public.

> 
> Ciao, Thorsten
> 



Thanks,
Mauro

On 16.11.24 11:42, Greg KH wrote:
> On Sat, Nov 16, 2024 at 10:33:59AM +0100, Thorsten Leemhuis wrote:
>> Point out that explicit permission is usually needed to tag other people
>> in changes, but mention that implicit permission can be sufficient in
>> certain cases. This fixes slight inconsistencies between Reported-by:
>> and Suggested-by: and makes the usage more intuitive.
>>
>> While at it, explicitly mention the dangers of our bugzilla instance, as
>> it makes it easy to forget that email addresses visible there are only
>> shown to logged-in users.
>>
>> The latter is not a theoretical issue, as one maintainer mentioned that
>> his employer received a EU GDPR (general data protection regulation)
>> complaint after exposing a email address used in bugzilla through a tag
>> in a patch description.
>>
>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> Cc: Simona Vetter <simona.vetter@ffwll.ch>
>> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
>> ---
>> Note: this triggers a few checkpatch.pl complaints that are irrelevant
>> when when to comes to changes like this.
>>
>> v2:
>> - Retry differently. This slightly hardens the rule for Reported-by:
>>   while slightly lessening it for Suggested-by:. Those in the end are
>>   quite similar, so it does not make much sense to apply different ones.
>>   I considered using an approach along the lines of "if you reported it
>>   in pubic by mail, implicit permission to use in a tag is granted"; but
>>   I abstained from it, as I assume there are good reasons for the
>>   existing approach regarding Suggested-by:.
>> - CC all the people that provided feedback on the text changes in v1
>>
>> v1: https://lore.kernel.org/all/f5bc0639a20d6fac68062466d5e3dd0519588d08.1731486825.git.linux@leemhuis.info/
>> - initial version
>> ---
>>  Documentation/process/5.Posting.rst          | 17 ++++++--
>>  Documentation/process/submitting-patches.rst | 44 ++++++++++++++------
>>  2 files changed, 45 insertions(+), 16 deletions(-)
>>
>> diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
>> index dbb763a8de901d..b45c4f6d65ca95 100644
>> --- a/Documentation/process/5.Posting.rst
>> +++ b/Documentation/process/5.Posting.rst
>> @@ -268,10 +268,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.
>> +Be careful in the addition of tags to your patches, as nearly all of them need
>> +explicit permission of the person named.
>> +
>> +The only exceptions are Cc:, Reported-by:, and Suggested-by:, as for them
> 
> I don't understand what you mean by "only exceptions" here.  Exceptions
> to what?

"Exception" to what is mentioned in the sentence before that and hinted
at with "nearly" there. Hmmm. Wondering if this is just not obvious
enough due to the newlines.

>> +implicit permission is sufficient under the following circumstances: when the
>> +person named according to the lore archives or the commit history regularly
>> +contributes to the Linux kernel using that name and email address -- and in
>> +case of Reported-by: and Suggested-by: did the reporting or suggestion in
>> +public. For all other situations explicit permission is required to among
>> +others prevent exposing email addresses considered private. Especially ask for
>> +permission when it comes to bug trackers, as most only show addresses to logged
>> +in users; that includes bugzilla.kernel.org, whose privacy policy explicitly
>> +states that 'your email address will never be displayed to logged out users'.
> 
> How about makeing this much simpler, basically "any public reference can
> be used, but please note, email addresses in bugzilla.kernel.org are not
> public.  Anything offered in private should probably not be referenced."
> or something like that?

Well, as hinted in the note for v2 above: I'm all for that and maybe I'm
just overly careful (aka a coward ;-) ) here -- but in the end did not
go that far due to the "Please note that this tag should not be added
without the reporter’s permission, especially if the idea was not posted
in a public forum." that's currently in submitting-patches, as there
might be reasons why it was written like that way (which sounds like
"public is not enough" to my ears).

Ciao, Thorsten