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: <aIPp4R7Xd_10J2uH@gallifrey>
Date: Fri, 25 Jul 2025 20:32:33 +0000
From: "Dr. David Alan Gilbert" <linux@...blig.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, Sasha Levin <sashal@...nel.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

* Jakub Kicinski (kuba@...nel.org) wrote:
> On Fri, 25 Jul 2025 15:00:46 -0400 Steven Rostedt wrote:
> > On Fri, 25 Jul 2025 11:41:14 -0700
> > Jakub Kicinski <kuba@...nel.org> wrote:
> > > On Fri, 25 Jul 2025 13:53:56 -0400 Sasha Levin wrote:  
> > > > 	Co-developed-by: Claude claude-opus-4-20250514
> > > > 	---
> > > > 	 Documentation/power/opp.rst | 2 +-
> > > > 	 1 file changed, 1 insertion(+), 1 deletion(-)    
> > > 
> > > I think we should suggest that the tag is under --- ?
> > > It's only relevant during the review. Once the patch is committed 
> > > whether the code was organic or generated by Corp XYZ's Banana AI
> > > is just free advertising..  
> > 
> > What's the difference between that and others using their corporate email?
> > I even add (Google) to my SoB to denote who is paying me to do the work.
> 
> 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.

People have done it (using inconsistent tags and comments) for things
like Coverity for years;  some people worry a lot about AI, some not at all;
adding a tag:
  a) Lets the people who worry keep of track what our mechanical overlords are
doing.
  b) Reviewers who are wary of slop get to cast a careful eye.
  c) Gives the tools (and their developers) suitable credit.  After all machines
need love too.

> > 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.

We carry lots more random stuff in commit messages!

Dave

-- 
 -----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   |_______/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ