docs: reminder to not expose potentially private email addresses
Subsystems (2)
v2 cover docs: reminder to not expose potentially private email addresses
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 -- especially when it comes to bugzilla.kernel.org.
This fixes a few issues along the way that came up during preparation or review of the change.
Ciao, Thorsten
---
v2:
- Intial version starting with "2", as the second patch was posted before.
Thorsten Leemhuis (2):
docs: 5.Posting: mentioned Suggested-by: tag
docs: clarify rules wrt tagging other people
Documentation/process/5.Posting.rst | 21 ++++++++-- Documentation/process/submitting-patches.rst | 44 ++++++++++++++------ 2 files changed, 49 insertions(+), 16 deletions(-)
base-commit: 623e5747c680d3854b6b9882d9907096bc63580d
Signature · 1 line
2.45.0
PATCH v2 1/2 docs: 5.Posting: mentioned Suggested-by: tag
Mentioned the Suggested-by: tag in 5.Posting.rst in a way similar to submitting-patches.rst, which according to the header of the latter is the less detailed document of the two.
--- Documentation/process/5.Posting.rst | 4 ++++ 1 file changed, 4 insertions(+)
Documentation/process/5.Posting.rst +4 -0
@@ -261,6 +261,10 @@ The tags in common use are: can be used instead of Closes: if the patch fixes a part of the issue(s) being reported. + - A Suggested-by: tag indicates that the patch idea is suggested by the person + named and ensures credit to the person for the idea. This will, hopefully, + inspire them to help us again in the future. + - Cc: the named person received a copy of the patch and had the opportunity to comment on it.
Signature · 1 line
2.45.0
Re: [PATCH v2 1/2] docs: 5.Posting: mentioned Suggested-by: tag
Quoted 27 lines · Thorsten Leemhuis
Mentioned the Suggested-by: tag in
5.Posting.rstin a way similar tosubmitting-patches.rst, which according to the header of the latter is the less detailed document of the two.Signed-off-by Thorsten Leemhuis <[email protected]>--- Documentation/process/5.Posting.rst | 4 ++++ 1 file changed, 4 insertions(+)Documentation/process/5.Posting.rst +4
-0@@ -261,6 +261,10 @@ The tags in common use are: can be used instead of Closes: if the patch fixes a part of the issue(s) being reported. + - A Suggested-by: tag indicates that the patch idea is suggested by the person + named and ensures credit to the person for the idea. This will, hopefully, + inspire them to help us again in the future. + - Cc: the named person received a copy of the patch and had the opportunity to comment on it.Signature · 1 line
2.45.0
PATCH v2 2/2 docs: clarify rules wrt tagging other people
In reply to Thorsten LeemhuisPoint 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.
---
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(-)
Documentation/process/5.Posting.rst +13 -4
@@ -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
Documentation/process/submitting-patches.rst +32 -12
68 lines not on this page · raw message
Signature · 1 line
2.45.0
Re: [PATCH v2 2/2] docs: clarify rules wrt tagging other people
Quoted 45 lines · Thorsten Leemhuis
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 <[email protected]>Cc Simona Vetter <[email protected]>Cc Mauro Carvalho Chehab <[email protected]>Signed-off-by Thorsten Leemhuis <[email protected]>---
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 v1v1: 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(-)Documentation/process/5.Posting.rst +0
-0@@ -268,10 +268,19 @@ The tags in common use are: - Cc: the named person received a copy of the patch and had the
Documentation/process/5.Posting.rst The tags in common use are: · line 274
Quoted 10 lines
Documentation/process/5.Posting.rst +4
-4opportunity 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?
Documentation/process/5.Posting.rst The tags in common use are: · line 283
Quoted 9 lines
Documentation/process/5.Posting.rst +9
-0+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
Re: [PATCH v2 2/2] docs: clarify rules wrt tagging other people
Quoted 48 lines · Greg KH
Quoted 47 lines · Thorsten Leemhuis
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 <[email protected]>Cc Simona Vetter <[email protected]>Cc Mauro Carvalho Chehab <[email protected]>Signed-off-by Thorsten Leemhuis <[email protected]>---
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 v1v1: 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(-)Documentation/process/5.Posting.rst +0
-0@@ -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.
Quoted 11 lines
Documentation/process/5.Posting.rst The tags in common use are: · line 274
Quoted 8 lines
Documentation/process/5.Posting.rst +4
-4-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 themI 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.
Quoted 6 lines
Quoted 6 lines
Documentation/process/5.Posting.rst +6
-0+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
Quoted 8 lines
Documentation/process/5.Posting.rst The tags in common use are: · line 283
Quoted 3 lines
Documentation/process/5.Posting.rst +3
-0+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
Re: [PATCH v2 2/2] docs: clarify rules wrt tagging other people
In reply to Greg KHEm Sat, 16 Nov 2024 11:42:06 +0100
Greg KH <[email protected]> escreveu:
Quoted 60 lines · Thorsten Leemhuis
Quoted 45 lines
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 <[email protected]>Cc Simona Vetter <[email protected]>Cc Mauro Carvalho Chehab <[email protected]>Signed-off-by Thorsten Leemhuis <[email protected]>---
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 v1v1: 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(-)Documentation/process/5.Posting.rst +0
-0@@ -268,10 +268,19 @@ The tags in common use are: - Cc: the named person received a copy of the patch and had theDocumentation/process/5.Posting.rst The tags in common use are: · line 274
Quoted 10 lines
Documentation/process/5.Posting.rst +4
-4opportunity 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 themI don't understand what you mean by "only exceptions" here. Exceptions to what?
Quoted 3 lines
Documentation/process/5.Posting.rst The tags in common use are:
Quoted 3 lines
Documentation/process/5.Posting.rst +3
-0+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
Quoted 11 lines
Documentation/process/5.Posting.rst The tags in common use are: · line 283
Quoted 7 lines
and in
Documentation/process/5.Posting.rst +6
-0+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.
Quoted 6 lines
or something like that?
thanks,
greg k-h
Thanks,
Mauro
Re: [PATCH v2 2/2] docs: clarify rules wrt tagging other people
Quoted 75 lines · Mauro Carvalho Chehab
Em Sat, 16 Nov 2024 11:42:06 +0100
Greg KH <[email protected]> escreveu:Quoted 60 lines · Thorsten Leemhuis
Quoted 45 lines
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 <[email protected]>Cc Simona Vetter <[email protected]>Cc Mauro Carvalho Chehab <[email protected]>Signed-off-by Thorsten Leemhuis <[email protected]>---
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 v1v1: 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(-)Documentation/process/5.Posting.rst +0
-0@@ -268,10 +268,19 @@ The tags in common use are: - Cc: the named person received a copy of the patch and had theDocumentation/process/5.Posting.rst The tags in common use are: · line 274
Quoted 10 lines
Documentation/process/5.Posting.rst +4
-4opportunity 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 themI don't understand what you mean by "only exceptions" here. Exceptions to what?
Quoted 3 lines
Documentation/process/5.Posting.rst The tags in common use are:
Quoted 3 lines
Documentation/process/5.Posting.rst +3
-0+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.
Quoted 6 lines
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
Re: [PATCH v2 2/2] docs: clarify rules wrt tagging other people
Em Sat, 16 Nov 2024 13:27:44 +0100
Thorsten Leemhuis <[email protected]> escreveu:
Quoted 87 lines · Mauro Carvalho Chehab
Quoted 75 lines
Em Sat, 16 Nov 2024 11:42:06 +0100
Greg KH <[email protected]> escreveu:Quoted 60 lines · Thorsten Leemhuis
Quoted 45 lines
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 <[email protected]>Cc Simona Vetter <[email protected]>Cc Mauro Carvalho Chehab <[email protected]>Signed-off-by Thorsten Leemhuis <[email protected]>---
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 v1v1: 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(-)Documentation/process/5.Posting.rst +0
-0@@ -268,10 +268,19 @@ The tags in common use are: - Cc: the named person received a copy of the patch and had theDocumentation/process/5.Posting.rst The tags in common use are: · line 274
Quoted 10 lines
Documentation/process/5.Posting.rst +4
-4opportunity 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 themI don't understand what you mean by "only exceptions" here. Exceptions to what?
Quoted 3 lines
Documentation/process/5.Posting.rst The tags in common use are:
Quoted 3 lines
Documentation/process/5.Posting.rst +3
-0+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.
Quoted 6 lines
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.
Quoted 5 lines
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 [email protected] and the author may have just [email protected] - or vice-versa.
What about:
"""
commit with a 'Signed-off-by' tag or patch(es) authored or committed by that name and email address.
"""
Quoted 5 lines
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.
Quoted 3 lines
Ciao, Thorsten
Thanks,
Mauro
Re: [PATCH v2 2/2] docs: clarify rules wrt tagging other people
In reply to Thorsten LeemhuisHi Thorsten,
Quoted 4 lines · Thorsten Leemhuis
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
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] 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
Re: [PATCH v2 2/2] docs: clarify rules wrt tagging other people
Quoted 8 lines · Geert Uytterhoeven
Quoted 4 lines · Thorsten Leemhuis
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