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: <de260c56-d3dd-449c-b5af-4d85b268f90c@lucifer.local>
Date: Fri, 9 Jan 2026 07:28:01 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, Dave Hansen <dave@...1.net>,
        Dave Hansen <dave.hansen@...el.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        linux-kernel@...r.kernel.org, Shuah Khan <shuah@...nel.org>,
        Kees Cook <kees@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Miguel Ojeda <ojeda@...nel.org>, Luis Chamberlain <mcgrof@...nel.org>,
        SeongJae Park <sj@...nel.org>, Dan Williams <dan.j.williams@...el.com>,
        NeilBrown <neilb@...mail.net>, Theodore Ts'o <tytso@....edu>,
        Sasha Levin <sashal@...nel.org>, Jonathan Corbet <corbet@....net>,
        Vlastimil Babka <vbabka@...e.cz>, workflows@...r.kernel.org,
        ksummit@...ts.linux.dev
Subject: Re: [PATCH] [v3] Documentation: Provide guidelines for
 tool-generated content

On Fri, Jan 09, 2026 at 08:42:56AM +0300, Dan Carpenter wrote:
> On Thu, Jan 08, 2026 at 03:14:37PM -0500, Steven Rostedt wrote:
> > On Thu, 8 Jan 2026 11:50:29 -0800
> > Dave Hansen <dave@...1.net> wrote:
> >
> > > On 1/8/26 11:23, Lorenzo Stoakes wrote:
> > > > I'm also not sure why we're losing the scrutiny part?
> > > >
> > > > Something like:
> > > >
> > > > +If tools permit you to generate series entirely automatically, expect
> > > > +additional scrutiny.
> > >
> > > The reason I resisted integrating this is it tries to draw too specific
> > > a line in the sand. Someone could rightfully read that and say they
> > > don't expect additional scrutiny because the entire series was not
> > > automatically generated.
> > >
> > > What I want to say is: the more automation your tool provides, the more
> > > scrutiny you get. Maybe:
> > >
> > > 	Expect increasing amounts of maintainer scrutiny on
> > > 	contributions that were increasingly generated by tooling.
> >
> > Honestly that just sounds "grumpy" to me ;-)
> >
> > How about something like:
> >
> > 	All tooling is prone to make mistakes that differ from mistakes
> > 	generated by humans. A maintainer may push back harder on
> > 	submissions that were entirely or partially generated by tooling
> > 	and expect the submitter to demonstrate that even the generated
> > 	code was verified to be accurate.
> >
> > -- Steve
>
> It's better to have a grumpy document, instead of grumpy emails.  We
> need it to sound grumpy and it needs to be the first paragraph.
>
> AI Slop:  AI can generate a ton of patches automatically which creates a
> burden on the upstream maintainers.  The maintainers need to review
> every line of every patch and they expect the submitters to demonstrate
> that even the generated code was verified to be accurate.  If you are
> unsure of whether a patch is appropriate then do not send it.  NO AI
> SLOP!
>
> Of course, sensible people don't need to be told this stuff, but there
> are well intentioned people who need it explained.
>
> regards,
> dan carpenter
>

Exactly.

Every version of watering it down just makes it meaningless noise. The point is
to emphasise this.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ