Date: Sat, 21 Dec 2024 14:24:15 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Kyle Evans <kevans@FreeBSD.org>, "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Robert Clausecker <fuz@fuz.su>, freebsd-arch@FreeBSD.org Subject: Re: Removing shar(1) Message-ID: <20241221142415.250e3cd675b3e3f740684f6c@dec.sakura.ne.jp> In-Reply-To: <20241221035543.E9BA1447@slippy.cwsent.com> References: <202412201520.4BKFK2pH037264@gndrsh.dnsmgr.net> <15ff7220-9a07-46f6-a0fc-20fcf237ab25@FreeBSD.org> <20241221035543.E9BA1447@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Dec 2024 19:55:43 -0800 Cy Schubert <Cy.Schubert@cschubert.com> wrote: > 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. Wouldn't uuencode (1) / uudecode (1) or base64 usable for the purpose, without making text-encoded data executable script? BTW, in Japan, a software called "ish" was quite widely used on ancient BBS serivces. (Was relatively robust for transfer errors.) https://ja.wikipedia.org/wiki/Ish Unfortunately, the page above are in Japanese only (no other language versions). But found Unix version on ports. https://www.freshports.org/converters/ish/ and (maybe) its variant https://www.freshports.org/converters/aish/ Both are still build fine on stable/14, amd64. And tested the former using /usr/src/UPDATING as a sample, 87557 bytes is encoded to 120479 bytes, restored fine. Command lines (at my home directory): For encode: ish /usr/src/UPDATING -s -u -n -f=UPDATING.ish For decoding: ish UPDATING.ish -r For reading help: ish -help > > >>> 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 -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20241221142415.250e3cd675b3e3f740684f6c>