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: <aILb-zDiDr4b9u9S@gallifrey>
Date: Fri, 25 Jul 2025 01:20:59 +0000
From: "Dr. David Alan Gilbert" <linux@...blig.org>
To: Sasha Levin <sashal@...nel.org>
Cc: Kees Cook <kees@...nel.org>, Steven Rostedt <rostedt@...dmis.org>,
	Konstantin Ryabitsev <konstantin@...uxfoundation.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

* Sasha Levin (sashal@...nel.org) wrote:
> On Thu, Jul 24, 2025 at 04:54:11PM -0700, Kees Cook wrote:
> > On Thu, Jul 24, 2025 at 07:45:56PM -0400, Steven Rostedt wrote:
> > > My thought is to treat AI as another developer. If a developer helps you
> > > like the AI is helping you, would you give that developer credit for that
> > > work? If so, then you should also give credit to the tooling that's helping
> > > you.
> > > 
> > > I suggested adding a new tag to note any tool that has done non-trivial
> > > work to produce the patch where you give it credit if it has helped you as
> > > much as another developer that you would give credit to.
> > 
> > We've got tags to choose from already in that case:
> > 
> > Suggested-by: LLM
> > 
> > or
> > 
> > Co-developed-by: LLM <not@...an.with.legal.standing>
> > Signed-off-by: LLM <not@...an.with.legal.standing>
> > 
> > The latter seems ... not good, as it implies DCO SoB from a thing that
> > can't and hasn't acknowledged the DCO.
> 
> In my mind, "any tool" would also be something like gcc giving you a
> "non-trivial" error (think something like a buffer overflow warning that
> could have been a security issue).
> 
> In that case, should we encode the entire toolchain used for developing
> a patch?
> 
> Maybe...
> 
> Some sort of semi-standardized shorthand notation of the tooling used to
> develop a patch could be interesting not just for plain disclosure, but
> also to be able to trace back issues with patches ("oh! the author
> didn't see a warning because they use gcc 13 while the warning was added
> in gcc 14!").
> 
> Signed-off-by: John Doe <jd@...mple.com> # gcc:14.1;ccache:1.2;sparse:4.7;claude-code:0.5
> 
> This way some of it could be automated via git hooks and we can recommend
> a relevant string to add with checkpatch.

For me there are two separate things:
  a) A tool that found a problem
  b) A tool that wrote a piece of code.

I think the cases you're referring to are all (a), where as I'm mostly
thinking here about (b).
In the case of (a) it's normally _one_ of those tools that found it,
e.g. I see some:
   Found by gcc -fanalyzer

but we don't have a defined way to refer to them.
I also see a variety from coverity, e.g.
  Addresses-Coverity:  xxxxx
or the use of Link: to refer to a coverity failure
or
  Addresses-Coverity-ID: xxxx ("Description of it")

or a few others.
It would be great to standardise some of that as well.

Dave

> -- 
> Thanks,
> Sasha
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/