Re: Removing shar(1)

In message <0F5EE33E-DA7B-4615-BB32-33331D245D51@Wilcox-Tech.com>, "A. 
Wilcox"
writes:
> On Dec 20, 2024, at 9:55=E2=80=AFPM, Cy Schubert =
> <Cy.Schubert@cschubert.com>
> wrote:
> >=20
> > In message <15ff7220-9a07-46f6-a0fc-20fcf237ab25@FreeBSD.org>, Kyle =
> Evans=20
> > 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,
> >>>>>>>=20
> >>>>>>> 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.
> >>>>>>>=20
> >>>>>>=20
> >>>>>> 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.
> >>>>>=20
> >>>>> 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.
> >>>>>=20
> >>>>=20
> >>>> 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).
> >>>=20
> >>> 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.
> >>>=20
> >>=20
> >> I'm not arguing that the functionality needs to go for security =
> reasons,=20
> >> I'm arguing that we need to stop promoting the functionality as=20
> >> prominently as it is today.  I don't have any problem with people =
> using=20
> >> it for their own purposes, or with third parties that agree to it.  I=20=
>
> >> have problems with people that see shar(1) as a good option because =
> it's=20
> >> a first-class citizen along with the likes of cpio/tar/pax without=20
> >> considering the implications for the user of the archive.
> >=20
> > shar(1) should never be considered by people as a replacement of cpio, =
> tar=20
> > or zip. But it can do what the other tools cannot. For example, at =
> $JOB we=20
> > manage servers which do not have direct access to, i.e. no ssh or =
> other=20
> > direct network access. We use a virtual Windows desktop (called a =
> Secure=20
> > Access Gateway -- SAG - or Third Party Gateway, 3PG) in a secure =
> network=20
> > between our workstations and the servers. Getting a tarball from point =
> A to=20
> > point B is nearly impossible (except through a weird and lengthy path =
> of=20
> > shares). I will create a shar file of a directory tree, copy (cut & =
> paste)=20
> > it from my FreeBSD VM to a notepad and copy (cut & paste) that into a =
> PuTTY=20
> > session on the SAG. Then run it on the server within the secure =
> network,=20
> > extracting the files to enable me to perform post change QA, among =
> other=20
> > things. You can't cut & paste a tarball but you can cut & paste a shar =
> file.
> >=20
> > These networks are designed in such a way to make sure people can't=20
> > infiltrate or exfiltrate  data to/from the machines within the secure=20=
>
> > network. It's a kludgey workaround but it works.
>
>
> Isn=E2=80=99t that what uuencode(1) / uudecode(1) are for?

At the cost of increased size, yes.

>
> Granted, it requires uudecode to be present on the host.

These hosts don't have uudecode installed nor am I authorized to install it.

>
> Best,
> -Anna
>
> --
> Anna Wilcox (she/her)
> SW Engineering: C++/Rust, DevOps, POSIX, Py/Ruby
> Wilcox Technologies Inc.=



-- 
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