Re: Removing shar(1)

On Dec 20, 2024, at 9:55 PM, 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.


Isn’t that what uuencode(1) / uudecode(1) are for?

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

Best,
-Anna

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