From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28290 invoked from network); 23 Oct 2021 16:18:11 -0000 Received: from 4ess.inri.net (216.126.196.42) by inbox.vuxu.org with ESMTPUTF8; 23 Oct 2021 16:18:11 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 4ess; Sat Oct 23 12:13:05 -0400 2021 Message-ID: <00680B18A32088CC7A314C18D2CC07F2@felloff.net> Date: Sat, 23 Oct 2021 18:12:54 +0200 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <3C4C4D2C08BED22ADA0AB655C658BECA@eigenstate.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: package API API event Subject: Re: [9front] intent to delete: devssl, cpu, oexportfs, import Reply-To: 9front@9front.org Precedence: bulk > I'm gonig to look over this in the next few days, > but I think this can go in before we get rid of > devtls; cpu bypasses the handshake, so as long as > we keep devtls it should keep working regardless of > libsec. devtls is the one we use for tlsClient()/tlsServer(). we certainly do not want to get rid of devtls. cpu, import, oexportfs use devssl by calling pushssl(2), not devtls. pushssl() is using devssl only. there is not magic fallback to use devtls. -- cinap