Date: Fri, 20 Dec 2024 19:55:43 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> 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: <20241221035543.E9BA1447@slippy.cwsent.com> In-Reply-To: <15ff7220-9a07-46f6-a0fc-20fcf237ab25@FreeBSD.org> References: <202412201520.4BKFK2pH037264@gndrsh.dnsmgr.net> <15ff7220-9a07-46f6-a0fc-20fcf237ab25@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <15ff7220-9a07-46f6-a0fc-20fcf237ab25@FreeBSD.org>, Kyle Evans write s: > 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. shar(1) should never be considered by people as a replacement of cpio, tar or zip. But it can do what the other tools cannot. For example, at $JOB we manage servers which do not have direct access to, i.e. no ssh or other direct network access. We use a virtual Windows desktop (called a Secure Access Gateway -- SAG - or Third Party Gateway, 3PG) in a secure network between our workstations and the servers. Getting a tarball from point A to point B is nearly impossible (except through a weird and lengthy path of shares). I will create a shar file of a directory tree, copy (cut & paste) it from my FreeBSD VM to a notepad and copy (cut & paste) that into a PuTTY session on the SAG. Then run it on the server within the secure network, extracting the files to enable me to perform post change QA, among other things. You can't cut & paste a tarball but you can cut & paste a shar file. These networks are designed in such a way to make sure people can't infiltrate or exfiltrate data to/from the machines within the secure network. It's a kludgey workaround but it works. > > >> > >>> Your basically breaking things without any increase in security. > >>> > >>> FIRM NO here. > >>> > >>>> > >>>>> We should consider replacing shar(1) by an implementation that just cal > ls > >>>>> 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 > -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20241221035543.E9BA1447>