linux-kernel - Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content

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: <20260108131926.59b456fc@gandalf.local.home>
Date: Thu, 8 Jan 2026 13:19:26 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Dave Hansen <dave@...1.net>, Dave Hansen <dave.hansen@...ux.intel.com>,
 linux-kernel@...r.kernel.org, Shuah Khan <shuah@...nel.org>, Kees Cook
 <kees@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Miguel
 Ojeda <ojeda@...nel.org>, Luis Chamberlain <mcgrof@...nel.org>, SeongJae
 Park <sj@...nel.org>, Dan Williams <dan.j.williams@...el.com>, NeilBrown
 <neilb@...mail.net>, Theodore Ts'o <tytso@....edu>, Sasha Levin
 <sashal@...nel.org>, Jonathan Corbet <corbet@....net>, Vlastimil Babka
 <vbabka@...e.cz>, workflows@...r.kernel.org, ksummit@...ts.linux.dev
Subject: Re: [PATCH] [v3] Documentation: Provide guidelines for
 tool-generated content

On Thu, 8 Jan 2026 11:29:47 +0000
Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:

> > But one thing I learned about my decade on the TAB, is don't worry about
> > things you are afraid might happen, just make sure you address what is
> > currently happening. Especially when it's easy to update the rules.  
> 
> I mean why are we even writing the document at all in that case :) why did this
> discussion come up at the maintainer's summit, etc.

What happened that started this discussion was me reading about an AI patch
that was submitted and accepted without the maintainer knowing that the
patch was 100% created by AI. That maintainer just happened to be me! I
made a stink about not disclosing the fact that the patch was generated by
AI. I wanted full transparency.

A long discussion started there where we noticed that we have no written
policy on transparency of tooling used to create patches and wanted to fix
that. That was the reason this all started, but it expanded to "Oh we need
to document our policy on AI too". That was an after thought.

See why I'm still pushing to only document what our current policy is.

> 
> I think it's sensible to establish a clear policy on how we deal with this
> _ahead of time_.

Why? We don't know what is going to happen. We are only assuming things are
going to be a problem, where it may never be.

> 
> And as I said to Linus (and previously in discussions on this) I fear the
> press reporting 'linux kernel welcomes AI submissions, sees it like any
> other tool'.

But this document doesn't even say that. It's only expressing in writing
what our policy is on transparency of using tooling where AI is just one
more tool. AI submissions have already been done. It's only accepted after
the normal process is followed.

-- Steve