lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ce6c0fcb-0df2-473d-8286-dca67ba15066@leemhuis.info>
Date: Sat, 16 Nov 2024 12:07:09 +0100
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Jonathan Corbet <corbet@....net>, workflows@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 Simona Vetter <simona.vetter@...ll.ch>,
 Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Subject: Re: [PATCH v2 2/2] docs: clarify rules wrt tagging other people

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@...asonboard.com>
>> Cc: Simona Vetter <simona.vetter@...ll.ch>
>> Cc: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
>> Signed-off-by: Thorsten Leemhuis <linux@...mhuis.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ