Re: Removing shar(1)

On 12/18/24 07:47, Tomek CEDRO wrote:
> On Wed, Dec 18, 2024 at 3:27 AM Kyle Evans <kevans@freebsd.org> wrote:
>> Hi,
>> I was reminded the other day that shar(1) exists, though it's use is no
>> longer recommended in ports.  The same functionality can be found in
>> tar(1) instead, so I think we should deorbit /usr/bin/shar and stop
>> promoting it entirely.  sh(1) archives are really problematic from a
>> user standpoint for at least one reason best explained by the manpage:
>>    It is easy to insert trojan horses into shar files.  It is strongly
>>    recommended that all shell archive files be examined before running
>>    them through sh(1).  Archives produced using this implementation of
>>    shar may be easily examined with the command:
>>         egrep -av '^[X#]' shar.file
>> It's hard to advocate for their use in good conscience, much like it's
>> hard to advocate curl|sh pipes.
>> Review: https://reviews.freebsd.org/D48130
>> Thanks,
>> Kyle Evans
> 
> Hey there Kyle :-) Removing tools completely is not a good choice, but
> moving them from base to ports in case someone needs to use them for
> any reason would be a better choice? :-)
> 

That is traditionally how we handle these things, yes.

> There are still lots of installers using shar like approach, or even
> worse things like feeding shell scripts directly from a remote url
> (i.e. brew installer on macos).
> 

The install side doesn't need shar(1), the result is an archive that is 
to be executed by /bin/sh.  The generation side needs shar(1), and we 
also have tar(1) for that (which can generate shar-cives).

Thanks,

Kyle Evans