Re: Removing shar(1)

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.

>>
>>> Your basically breaking things without any increase in security.
>>>
>>> FIRM NO here.
>>>
>>>>
>>>>> We should consider replacing shar(1) by an implementation that just calls
>>>>> 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