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: <20241202092857.7d197995@foz.lan>
Date: Mon, 2 Dec 2024 09:28:57 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Thorsten Leemhuis <linux@...mhuis.info>
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>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v3 DONOTMERGE] docs: clarify rules wrt tagging other
 people

Em Mon,  2 Dec 2024 09:14:19 +0100
Thorsten Leemhuis <linux@...mhuis.info> escreveu:

> 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>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Signed-off-by: Thorsten Leemhuis <linux@...mhuis.info>

LGTM.

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>

> ---
> Note: this triggers a few checkpatch.pl complaints that are irrelevant
> when when to comes to changes like this.
> 
> v3:
> - try yet again from a slightly different angle which loosens the rules
>   slightly. This from review feedback to earlier versions is apparently
>   what other developers want and from their "no lawyer" perspective
>   consider to be okay. As IANAL myself I don't feel totally comfortable
>   with this and have no idea if this legally is sound, so tag patch with
>   "DONOTMERGE" for now; will remove this for v4 if enough people add a
>   "Reviewed-by". Otherwise the story of this patch might end here, unless
>   someone else submits it for inclusion (you are free to do so!).
> - remote patch adding Suggested-by: tag to 5.Posting and submit it
>   separately
> 
> v2: https://lore.kernel.org/all/cover.1731749544.git.linux@leemhuis.info/
> - 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          | 13 +++++--
>  Documentation/process/submitting-patches.rst | 39 ++++++++++++++------
>  2 files changed, 36 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
> index b3eff03ea2491c..73961565040ed8 100644
> --- a/Documentation/process/5.Posting.rst
> +++ b/Documentation/process/5.Posting.rst
> @@ -264,10 +264,15 @@ 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 all except for Cc:,
> +Reported-by:, and Suggested-by: need explicit permission of the person named.
> +For the three aforementioned ones implicit permission is sufficient if the
> +person contributed to the Linux kernel using that name and email address
> +according to the lore archives or the commit history -- and in case of
> +Reported-by: and Suggested-by: did the reporting or suggestion in public.
> +Note, bugzilla.kernel.org is a public place in this sense, but email addresses
> +used there are private; so do not expose them in tags, unless the person used
> +them in earlier contributions.
>  
>  
>  Sending the patch
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index 1518bd57adab50..9d26a4b7ca8ba3 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,21 @@ process nor the requirement to Cc: stable@...r.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 all except for Cc:,
> +Reported-by:, and Suggested-by: need explicit permission of the person named.
> +For the three aforementioned ones implicit permission is sufficient if the
> +person contributed to the Linux kernel using that name and email address
> +according to the lore archives or the commit history -- and in case of
> +Reported-by: and Suggested-by: did the reporting or suggestion in public.
> +Note, bugzilla.kernel.org is a public place in this sense, but email addresses
> +used there are private; so do not expose them in tags, unless the person used
> +them in earlier contributions.
> +
>  .. _the_canonical_patch_format:
>  
>  The canonical patch format
> 
> base-commit: 83a474c11e8cb59e230a43365cb42fa00d3bddaa



Thanks,
Mauro

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ