Re: Removing shar(1)

On Fri, 20 Dec 2024 19:55:43 -0800
Cy Schubert <[email protected]> wrote:

> In message <[email protected]>, 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 <[email protected]>
> FreeBSD UNIX:  <[email protected]>   Web:  https://FreeBSD.org
> NTP:           <[email protected]>    Web:  https://nwtime.org
> 
> 			e^(i*pi)+1=0


-- 
Tomoaki AOKI    <[email protected]>