Date: Fri, 20 Dec 2024 07:20:02 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Kyle Evans <kevans@FreeBSD.org> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Robert Clausecker <fuz@fuz.su>, freebsd-arch@FreeBSD.org Subject: Re: Removing shar(1) Message-ID: <202412201520.4BKFK2pH037264@gndrsh.dnsmgr.net> In-Reply-To: <348991f2-ab8f-4b0e-b171-bb7de10b1112@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202412201520.4BKFK2pH037264>