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] [day] [month] [year] [list]
Date: Mon, 08 May 2023 07:51:37 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>, Chuck Lever <cel@...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, 2023-05-05 at 16:47 -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?)..

Really, I' not ;)

My guess is that net/handshake is going to be dependent more on core
networking changes than anything else. If later developments will
require/use/leverage a new core net helper, it would be quite straight-
forward going trough the netdev trees. Otherwise such changes will
require extra coordination and/or an additional RTT WRT kernel
releases.

All the above very much IMHO ;)

/P


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ