linux-kernel - Re: [PATCH 0/4] Add agent coding assistant configuration to Linux kernel

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: <30b5f616-4d0f-48d8-8342-219431ab264d@lucifer.local>
Date: Wed, 30 Jul 2025 19:18:48 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Sasha Levin <sashal@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, Greg KH <greg@...ah.com>,
        corbet@....net, linux-doc@...r.kernel.org, workflows@...r.kernel.org,
        josh@...htriplett.org, kees@...nel.org, konstantin@...uxfoundation.org,
        linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Dr. David Alan Gilbert" <linux@...blig.org>
Subject: Re: [PATCH 0/4] Add agent coding assistant configuration to Linux
 kernel

On Wed, Jul 30, 2025 at 02:03:38PM -0400, Sasha Levin wrote:
> On Wed, Jul 30, 2025 at 01:32:20PM -0400, Steven Rostedt wrote:
> > On Wed, 30 Jul 2025 18:23:14 +0100
> > Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> > > You might suggest presuming a policy for maintainers is inappropriate, but
> > > you are doing so wrt the LF policy on the assumption everybody is aware and
> > > agrees with it.
>
> No, this isn't about the LF policy. Let's completely ignore it for the
> sake of this discussion.

Ack.

>
> All we require now is a signed DCO. The kernel's own policy, based on
> Documentation/, is that we don't even need to disclose tool usage.

Right, yeah, this seems to be sort of implicit though, or sort of 'by
accident' ultimately (I mean who could have seen this stuff coming right?
:)

>
> > > That same document says individual projects can _override_ this as they
> > > please. So the introduction of this document can very well override that.
> > >
> > > We at the very least need this to be raised at the maintainers summit with
> > > a very clear decision on opt-in vs. opt-out, with the decision being
> > > communicated clearly.
> >
> > Agreed.
>
> Right - if this is brought up during maintainer's summit and most folks
> are in favor of "red" (or Linus just makes a desicion), we can go ahead
> and adopt our own policy and set it to "red".

I think this shouldn't be an 'if' :)

I'm not usually invited to the MS so I shall leave this to those who are to
ensure this is brought up :P

But I think it's an important thing to get some form of community consensus on.

>
> What I'm saying is that we can't just arbitrarily set it to "red" based
> on this thread as this is a change from our current policy

OK so I think we're in agreement then that deferring to the maintainer's
summit or some form of community consensus is the right way to go :)

And agreed, this thread is more a healthy expression of opinions in figuring
out the problem space more than anything in my view.

Nothing should be arbitrarily decided here of course.

Cheers, Lorenzo