From nobody Fri Dec 20 15:20:02 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YFB1P37g1z5WrCc for ; Fri, 20 Dec 2024 15:20:09 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YFB1P0qCcz4rbG; Fri, 20 Dec 2024 15:20:09 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 4BKFK26A037265; Fri, 20 Dec 2024 07:20:02 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 4BKFK2pH037264; Fri, 20 Dec 2024 07:20:02 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202412201520.4BKFK2pH037264@gndrsh.dnsmgr.net> Subject: Re: Removing shar(1) In-Reply-To: <348991f2-ab8f-4b0e-b171-bb7de10b1112@FreeBSD.org> To: Kyle Evans Date: Fri, 20 Dec 2024 07:20:02 -0800 (PST) CC: "Rodney W. Grimes" , Robert Clausecker , freebsd-arch@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] X-Rspamd-Queue-Id: 4YFB1P0qCcz4rbG X-Spamd-Bar: ---- > On 12/20/24 08:56, Rodney W. Grimes wrote: > >> On 12/18/24 05:04, Robert Clausecker wrote: > >>> Hi Kyle, > >>> > >>> With shar no longer being recommended for the submission of new ports, > >>> I see no objection to removing this feature. However, tar(1) should > >>> keep the functionality. > >>> > >> > >> I make no proposal to remove it from tar- that'd be really annoying > >> after recommending people use tar(1) instead both here and in the patch > >> below. > > > > Isnt this a bit oxy-moronic? Remove shar, yet point people to the exact > > same behavior in another binary shipped with the system? Your basically > > leaving the foot shooting neck hanging rope in the system and doing zip > > to remove the fact this fucntionality should NOT be removed. > > > > No, because the pointer is gone once shar(1) is gone. The functionality > will not removed, just the convenient front-end. You still have tar(1). If you dont remove the functionality the sum game is zero improvement. You have done NOTHING but remove a pointer (shar) to a function. In my book that is security through obscurity and just silly. If the shar create function needs to go because of security it nneds to go from ALL places. > > > Your basically breaking things without any increase in security. > > > > FIRM NO here. > > > >> > >>> We should consider replacing shar(1) by an implementation that just calls > >>> into tar(1) to do its job. > >>> > >> > >> Strongly prefer not to if we can avoid it (I'm not seeing any arguments > >> that we really need it to be a first-class citizen); I view that as > >> promoting functionality that we shouldn't be encouraging, along with > >> providing a manpage. > > > > Basically your just making it inconvinvient to get to the rope for those > > that do know how to not hang themselves. > > > > The rope is also great for hanging others, and it'd be great to shove it > behind all of the better tools in the shed. Obscurity process is NOT what BSD does. > What actual reasoning do you have for keeping shar(1) specifically? I didnt site any. I sited that your removing half of the problem is not a reasonable approach. Either remove it totally or do not touch it at all. > Your entire argument so far boils down to "You shouldn't remove it," Wow, really, thats how you read it. > which isn't particularly compelling. Its use should absolutely not be > encouraged in 2024 (or 2025, since that's apparently hiding around the > corner) and neither should any of the other abominations that we've > mentioned in this thread. > > Thanks, > > Kyle Evans > > > -- Rod Grimes rgrimes@freebsd.org