linux-kernel - Re: [PATCH v2] Documentation/CoC: spell out enforcement for unacceptable behaviors

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a1863858-a209-4b59-9161-5e57acb566d5@intel.com>
Date: Tue, 12 Nov 2024 11:37:04 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Daniel Vetter <daniel@...ll.ch>, Shuah Khan <skhan@...uxfoundation.org>
Cc: gregkh@...uxfoundation.org, corbet@....net, workflows@...r.kernel.org,
 rdunlap@...radead.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, Linus Torvalds
 <torvalds@...ux-foundation.org>, Miguel Ojeda <ojeda@...nel.org>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 Steven Rostedt <rostedt@...dmis.org>, Dan Williams
 <dan.j.williams@...el.com>, Theodore Ts'o <tytso@....edu>
Subject: Re: [PATCH v2] Documentation/CoC: spell out enforcement for
 unacceptable behaviors

On 11/12/24 11:21, Daniel Vetter wrote:
> Also, if a maintainer refuses to implement an enforcement decision,
> will they be sanctioned too? Since this is all an entirely new section
> and does not touch any of the existing sections I'm also not clear on
> when one or the other rules apply, and how they interact.

I don't think this is or _should_ take away any ability for a maintainer
to manage their subsystem.  It's not special at all, actually.

Let's say the CoC committee recommends "denying patch contributions and
pull requests". I as a maintainer either actively ignore the
recommendation or didn't notice the recommendation in my normal email
flood. I integrate a patch and send it along to the upstream maintainer.
The upstream maintainer looks over the pull request and like normal
either pulls it or says no.

If I intentionally disregarded the CoC committee recommendation for good
reason, I'd be a smart maintainer to note that in the pull request, just
like any other anomaly.

But either way, just like _any_ patch or pull request: there are few
absolute rules. Breaking userspace is highly discouraged, but allowed in
some cases.  Going against a CoC recommendation is also discouraged but
I don't think there should be absolute prohibition against it.

In the end, the upstream maintainer gets to decide what to do.