From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ds.inri.net ([107.191.103.21]) by ur; Tue Aug 9 13:59:51 EDT 2016 Received: from [10.223.88.163] ([166.175.57.96]) by ds; Tue Aug 9 13:59:51 EDT 2016 User-Agent: K-9 Mail for Android In-Reply-To: <0708b70b1ecfa9b6866bde2d5b038acb@felloff.net> References: <0708b70b1ecfa9b6866bde2d5b038acb@felloff.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Subject: Re: [9front] inquery: plans for phasing out cpu, rx and import From: stanley lieber Date: Tue, 09 Aug 2016 13:59:45 -0400 To: 9front@9front.org Message-ID: List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: compliant webscale framework method-based map/reduce API database cinap_lenrek@felloff=2Enet wrote: >> Disabling the listeners on 9front is = obvious, and since Plan 9 is >dead, maintenance is not really needed, but w= hy remove it, exactly? >Just to feel "clean"? > >i just recently fixed a bu= g in devssl=2Ec=2E its not like if labs doesnt >change >the protocol anymor= e, the impementation was bugfree=2E worse, this bug >could >be used to disr= upt the whole system, not just break security of the >weakly >encrypted con= nection=2E > >-- >cinap I guess I did not grasp that leaving the old cpu k= ernel bits in place still represented a security risk even if nobody is run= ning the old listeners=2E If that is the case then I agree we should remove= the stuff (and perhaps make it available in /n/extra)=2E sl