Date: Fri, 20 Dec 2024 09:37:50 -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: <15ff7220-9a07-46f6-a0fc-20fcf237ab25@FreeBSD.org> In-Reply-To: <202412201520.4BKFK2pH037264@gndrsh.dnsmgr.net> References: <202412201520.4BKFK2pH037264@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/20/24 09:20, Rodney W. Grimes wrote: >> 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. > I'm not arguing that the functionality needs to go for security reasons, I'm arguing that we need to stop promoting the functionality as prominently as it is today. I don't have any problem with people using it for their own purposes, or with third parties that agree to it. I have problems with people that see shar(1) as a good option because it's a first-class citizen along with the likes of cpio/tar/pax without considering the implications for the user of the archive. >> >>> 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. > Feel free to explain it more clearly, then. Thanks, Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15ff7220-9a07-46f6-a0fc-20fcf237ab25>