netdev - Re: [PATCH 0/5] Bug fixes for net/handshake

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: <ZFWYNW4JAOWX6ASq@manet.1015granger.net>
Date: Fri, 5 May 2023 19:58:45 -0400
From: Chuck Lever <cel@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: kernel-tls-handshake@...ts.linux.dev, netdev@...r.kernel.org,
	dan.carpenter@...aro.org
Subject: Re: [PATCH 0/5] Bug fixes for net/handshake

On Fri, May 05, 2023 at 04:47:15PM -0700, Jakub Kicinski wrote:
> On Fri, 5 May 2023 19:16:40 -0400 Chuck Lever wrote:
> > On Fri, May 05, 2023 at 01:39:18PM -0700, Jakub Kicinski wrote:
> > > On Thu, 04 May 2023 11:24:12 -0400 Chuck Lever wrote:  
> > > > I plan to send these as part of a 6.4-rc PR.  
> > > 
> > > Can you elaborate?  You'll send us the same code as PR?
> > > I'm about to send the first batch of fixes to Linus,
> > > I was going to apply this series.  
> > 
> > Since I am listed as a maintainer/supporter of net/handshake, I
> > assumed I can and should be sending changes through nfsd or some
> > other repo I can commit to.
> > 
> > netdev@ is also listed in MAINTAINERS, so I Cc'd you all on this
> > series. I did not intend for you to be responsible for merging the
> > series. We'll need to agree on a workflow going forward.
> 
> Let me talk to DaveM and Paolo -- with NFS being the main user
> taking it via your trees is likely fine. But if it's a generic TLS
> handshake and other users will appear - netdev trees may be a more
> natural central point :S DaveM and Paolo are more familiar with
> existing cases of similar nature (rxrpc?)..

Makes sense. We expect NVMe to become a consumer in the near future,
and have considered a putative in-kernel QUIC implementation to be
another potential consumer down the road.