linux-kernel - Re: [RFC PATCH] docs: submitting-patches: (AI?) Tool disclosure tag

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: <202507241337.F9595E1D@keescook>
Date: Thu, 24 Jul 2025 13:45:35 -0700
From: Kees Cook <kees@...nel.org>
To: Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Cc: linux@...blig.org, corbet@....net, workflows@...r.kernel.org,
	josh@...htriplett.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] docs: submitting-patches: (AI?) Tool disclosure tag

On Thu, Jul 24, 2025 at 03:07:17PM -0400, Konstantin Ryabitsev wrote:
> On Thu, Jul 24, 2025 at 06:54:39PM +0100, linux@...blig.org wrote:
> > From: "Dr. David Alan Gilbert" <linux@...blig.org>
> > 
> > It seems right to require that code which is automatically
> > generated is disclosed in the commit message.
> 
> I'm not sure that's the case. There is a lot of automatically generated
> content being added to the kernel all the time -- such as auto-formatted code,
> documentation, and unit tests generated by non-AI tooling. We've not required
> indicating this usage before, so I'm not sure it makes sense to start doing it
> now.
> 
> Furthermore, merely indicating the tool doesn't really say anything about how
> it was used (e.g. what version, what prompt, what context, etc.) If anything,
> this information needs to live in the cover letter of the submission. I would
> suggest we investigate encouraging contributors to disclose this there, e.g.:
> 
> | ---
> | This patch series was partially generated with "InsensitiveClod o4 Hokus"
> | and then heavily modified to remove the parts where it went completely off
> | the deep end.
> 
> I am also not opposed to having a more standard cover letter footer that would
> allow an easier way to query this information via public-inbox services, e.g.:
> 
> | generated-by: insensitive clod o4 hokus
> 
> However, I don't really think this belongs in the commit trailers.

I agree; I'm not sure I see a benefit in creating a regularized trailer
for this. What automation/tracking is going to key off of it? It's
a detail of patch creation methodology, so the commentary about how
something was created is best put in the prose areas, like we already
do for Coccinelle or other scripts. It's a bit buried in the Researcher
Guidelines[1], but we have explicitly asked for details about tooling:

  When sending patches produced from research, the commit logs should
  contain at least the following details, so that developers have
  appropriate context for understanding the contribution.
  ...
  Specifically include details about any testing, static or dynamic
  analysis programs, and any other tools or methods used to perform the
  work.

Maybe that needs to be repeated in SubmittingPatches?

-Kees

[1] https://docs.kernel.org/process/researcher-guidelines.html

-- 
Kees Cook