Date: Fri, 20 Dec 2024 09:03:23 -0600 From: Kyle Evans <kevans@FreeBSD.org> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: Robert Clausecker <fuz@fuz.su>, freebsd-arch@FreeBSD.org Subject: Re: Removing shar(1) Message-ID: <348991f2-ab8f-4b0e-b171-bb7de10b1112@FreeBSD.org> In-Reply-To: <202412201456.4BKEutl3037180@gndrsh.dnsmgr.net> References: <202412201456.4BKEutl3037180@gndrsh.dnsmgr.net>
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). > 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. What actual reasoning do you have for keeping shar(1) specifically? Your entire argument so far boils down to "You shouldn't remove 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?348991f2-ab8f-4b0e-b171-bb7de10b1112>