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

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

Message-ID: <aILYj62tF_1mDjDO@lappy>
Date: Thu, 24 Jul 2025 21:06:23 -0400
From: Sasha Levin <sashal@...nel.org>
To: Kees Cook <kees@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
	"Dr. David Alan Gilbert" <linux@...blig.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

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.

-- 
Thanks,
Sasha