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 26700 invoked from network); 2 Jun 2021 14:36:41 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2021 14:36:41 -0000 Received: from orthanc.ca ([208.79.93.154]) by 1ess; Wed Jun 2 00:37:15 -0400 2021 Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (OpenSMTPD) with ESMTP id bfc0b94a; Tue, 1 Jun 2021 21:30:34 -0700 (PDT) From: "Lyndon Nerenberg (VE7TFX/VE6BBM)" To: 9front@9front.org, ori@eigenstate.org In-reply-to: References: Comments: In-reply-to ori@eigenstate.org message dated "Tue, 01 Jun 2021 17:38:58 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <60740.1622608233.1@orthanc.ca> Date: Tue, 01 Jun 2021 21:30:33 -0700 Message-ID: <0322ce98856002de@orthanc.ca> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: rails hardware package Subject: Re: [9front] [patch] devtls updates Reply-To: 9front@9front.org Precedence: bulk > For tls, I'd be ok with keeping specific > obsolete ciphers around if there are > devices that need it You could overload the encalgs and hashalgs files to allow writes of '-hashalg' to remove an entry from the supported list. In fact, I think it might be useful to have a general write interface on those files where +alg adds to the list, -alg removes from the list, and any other write specifies an absolute list of algs to turn on. This would give the host owner fine grained control over what TLS would be willing to do (and, of course, allow them to break things in spectacular fashion). Removing write perms on either of the files would permanently make the underlying alg list immutable. In conjunction with that, add a '#aX' aname (that's a literal 'X' character, not a place holder) that references a TLS stack instance with all the obsolete algs available, but not necessarily enabled. Running 'bind -a '#aX' /net' would present, e.g., a /net/tls.insecure directory tree. Then things like cpu and oexportfs would have to bind /net/tls.insecure over /net/tls to get access to the old cruft. It would be good to have a switch that disabled binding the '#aX' device completely. That would allow the host owner to easily prevent the old stuff from ever being used. Once disabled, it can't be turned on again. Anyway, that's just something that sprang to mind when I read the question. Take it with the full five minutes thought I've given it. --lyndon