linux-kernel - Re: [RFC 0/2] Add AI 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: <aIQE-hkg5ehHaSZi@lappy>
Date: Fri, 25 Jul 2025 18:28:10 -0400
From: Sasha Levin <sashal@...nel.org>
To: dan.j.williams@...el.com
Cc: Jakub Kicinski <kuba@...nel.org>, Steven Rostedt <rostedt@...dmis.org>,
	workflows@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, kees@...nel.org,
	konstantin@...uxfoundation.org, corbet@....net,
	josh@...htriplett.org
Subject: Re: [RFC 0/2] Add AI coding assistant configuration to Linux kernel

On Fri, Jul 25, 2025 at 01:34:32PM -0700, dan.j.williams@...el.com wrote:
>Jakub Kicinski wrote:
>[..]
>> To be clear, it's not my main point, my main point is that
>> the information is of no proven use right now. As long as
>> committer follows the BKP of adding Link: https://patch.msgid.link/...
>> we can find the metadata later.
>>
>> We never found the need to attach the exact version of smatch / sparse
>> / cocci that found the bug or "wrote" a patch. Let us not overreact to
>> the AI tools.
>>
>> > Also, I would argue that it would be useful in the change log as if there's
>> > a bug in the generated code, you know who or *what* to blame. Especially if
>> > there is a pattern to be found.
>>
>> This touches on explainability of AI. Perhaps the metadata would be
>> interesting for XAI research... not sure that's enough to be lugging
>> those tags in git history.
>
>Agree. The "who to blame" is "Author:". They signed DCO they are
>responsible for debugging what went wrong in any stage of the
>development of a patch per usual. We have a long history of debugging
>tool problems without tracking tool versions in git history.

And it would be great to avoid the potential "it wasn't me, it was the
AI!" or "whoops I don't know how that exploitable issue ended up in my
patch, must have been the AI".

-- 
Thanks,
Sasha