linux-kernel - Re: [PATCH v4] docs: clarify rules wrt tagging other people

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] [day] [month] [year] [list]

Message-ID: <8b87b297-b68b-4276-95ae-e04650c3360f@leemhuis.info>
Date: Tue, 11 Feb 2025 09:48:36 +0100
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Jonathan Corbet <corbet@....net>
Cc: 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>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH v4] docs: clarify rules wrt tagging other people

On 10.02.25 19:12, Jonathan Corbet wrote:
> Thorsten Leemhuis <linux@...mhuis.info> writes:
>> 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.
> [...]
>> Jonathan, what do you think of this? I felt somewhat unsure about this a
>> few weeks ago, but I guess I was overly careful. If you think this
>> change is fine and shouldn't cause any trouble for anyone, feel free to
>> merge this. And if not, please speak up.
> 
> I have a couple of thoughts, neither of which is sufficient for me to
> oppose the change if there is consensus for it:
> 
> - You're saying that people need to grep email addresses out of the git
>   history before crediting them in a tag; that's not a step we have
>   required of people before and seems like a bit much..?

Do I? I don't think so. The phrase used is "name and email address
according to the lore archives *or* the commit history". I'd say that is
no extra work in most cases, as developers frequently interact with the
same set of people. And when not: most development happens by mail, so
all that is needed is a simply simple "is some list archived on lore
among the recipients". But sure, if you deal with someone in bugzilla or
say gitlab.freedesktop.org it becomes somewhat harder.

> - It would be awfully nice if we could provide this advice in exactly
>   one place in the document.  This is one of our most important docs,
>   and it is far too long to expect new contributors to read through and
>   absorb.  Avoiding making it longer and more repetitive would be
>   better, if we can.

Well, in 5.Posting.rst that was possible. In submitting-patches.rst that
conflicted with existing text in three areas, so some changes were
needed; in one case the new text even got a little shorter, but overall
those changes did not add a single new line.

But sure, the new paragraph added a few lines. And it is identical in
both documents. But that is a more complex and existing situation this
patch can't solve. But of course I could avoid adding the new paragraph
to submitting-patches.rst and change the "(see 'Tagging people requires
permission' below for details)" added there already into "(see 'Tagging
people requires permission' in Documentation/process/5.Posting.rst for
details)". Given that people requested a even more detailed paragraph
(see the other reply I just sent to Laurent) that might be wise; OTOH
submitting-patches.rst right now AFAICS tries to be stand-alone, so it
feels wrong at the same time.

IOW: both is fine for me. Could you let me please know what you prefer?

> - I wonder if it would make sense to say that, if an implicit-permission
>   tag has been added, the person named in it should get at least one
>   copy of the change before it is merged?

Hah, that is where I'd start to say "that seems like a bit much". And it
does not help, as the cat is out of the bag once that copy is out, as
the name and the email address someone might prefer to keep private
would have made it to mailing list archives then already.

> OK, three thoughts, you know what they say about off-by-one errors :)

:-D

Ciao, Thorsten