Re: Removing shar(1)

On Wed, 18 Dec 2024 07:47:41 -0600
Kyle Evans <[email protected]> wrote:

> On 12/18/24 03:22, Tomoaki AOKI wrote:
> > On Tue, 17 Dec 2024 20:27:16 -0600
> > Kyle Evans <[email protected]> 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
> > 
> > Unfortunately, there's some reporters (sorry, lost track with examples)
> > providing error outputs and/or patches as shar files.
> > (I myself dislike it, though, and consider them as "nonexistent" unless
> > it is a set of patches and multiple comments "it works" are posted.)
> > 
> > If we drop it, such users would complain. But when I really need the
> > contents to look into the problem, I usually request the reporters to
> > re-upload the contents as flat texts or non-executable archives like
> > *.txz.
> > 
> 
> The behavior is still there in tar(1), but these are the cases that I 
> don't sympathize with even remotely.  I feel even stronger about this 
> than the original proposal here- we should absolutely be discouraging 
> this in our own bug tracker.  If you want to use these between your own 
> systems, that's fine, but don't make the users of our bug trackers have 
> to be even more paranoid about attachments.

The persons who want shar is not me. ;-)
I'm at the opposite side.


> > And IIRC, RPMs for Linux binaries containing install-time scripts would
> > have similar problems.
> > 
> 
> Can you expand on that?  Why are install-time scripts generating 
> shar-cives, and what's happening with the results?  Why are they running 
> in a context with host tools and not a linux jail/chroot?

Most of the points are already noted by Tomek.

Some appendixes (actually, not limited with RPM).

Not install-time script generats shar archive, but the install-time
script could be generated AS something like shar-archived script.
Maybe official (RedHat) RPM packages would be checked and being fine,
but any of in-the-wild and INSANE projects (like at a point of xz) using
RPM to distribute their own packages can include something malicious in
their RPMs (or any other package systems).

AFAIK (not every ports, though), install-time scripts on ports are not
self-extracting and/or fetch and execute some executables (including
scripts) not included in pkg / stagedir. But I'm not sure how other
fistribution formats are.

Regards.

> 
> Thanks,
> 
> Kyle Evans


-- 
Tomoaki AOKI    <[email protected]>