Re: Removing shar(1)
- Reply: Tomoaki AOKI : "Re: Removing shar(1)"
- In reply to: Tomoaki AOKI : "Re: Removing shar(1)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 18 Dec 2024 13:47:41 UTC
On 12/18/24 03:22, Tomoaki AOKI wrote: > On Tue, 17 Dec 2024 20:27:16 -0600 > 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 > > 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. > 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? Thanks, Kyle Evans