As I look at it, those points correctly illustrate that this is not the greatest AUR helper out there. I will not disagree with that. (For example, the resurgence of bauerbill is refreshing.)
However, I at present do not believe spinach is "risky." It does not source the PKGBUILD directly. I do not think it will allow arbitrary code execution before viewing unless there is a method for executing code in a string in Bash other than with tick marks or $(...). I would easily be convinced that it is risky if I could find such an example. Note that such things are listed in a security section in the man page. Though, as you said, I could (and should) change this fairly easily to use a more modern method. In my view this discussion might be more suited as a bug report for spinach rather than a cause for deleting the package, but delete it if you wish. On Tue, Oct 24, 2017 at 3:48 PM, Alad Wenter <[email protected]> wrote: > > Garrett <[email protected]> hat am 24. Oktober 2017 um 21:57 > geschrieben: > > > > > > I would be fine with removing it from the AUR helpers page as there are > > presently many Bash AUR helpers. I don't know why it should be removed > from > > the AUR though. > > > The reason is that these undeveloped helpers have no purpose in 2017, > apart from to expose users to risky practice. > > > This is not a clone of yaourt. Though according to the AUR Helpers page > it > > is as secure as yaourt, i.e., not very secure except for spinach you'd > have > > to do some interesting escaping (that to my present knowledge is not > > possible, but there might be some way to do it) to get around the > function > > that cleans what is sourced for finding the depends. Yaourt package is > 0.53 > Since at least 2014 it's trivial to retrieve dependencies via the AUR RPC, > and any reasonable helper does exactly that. Even if the RPC does not > contain some information that the PKGBUILD does, it's easy to retrieve the > .SRCINFO instead. > > > MiB whereas the spinach package is 23 KiB. It was originally created for > > being very small and only doing the minimum required while still being > fast > > and useful. At the time (and maybe still now) I don't think many of the > > others were as small while still having features like downloading updates > > in multiple "threads". Also not sure if any of the others allow > installing > The "size" is nothing special and comparable to any of the script helpers. > Threads are mostly useless since the arrival of the multiinfo interface. > (See the related discussion on the AUR helper wiki article) > > > from a local directory of PKGBUILDs. Since I haven't used all of them I > Not sure how (a customizepkg variant) is useful when spinach can't > properly resolve dependencies to begin with. > > > don't really know how it compares to everything out there. Not saying > it's > > the greatest, but I think it has uses. > Maybe in 2011. Right now it might serve as historical perspective for > those writing their own AUR helpers (and in fact, I wouldn't mind having a > "Defunct AUR helpers" or such section on the wiki). Otherwise you should > look at a helper which uses modern, safe methods. > > > > > On Tue, Oct 24, 2017 at 9:27 AM, <[email protected]> wrote: > > > > > Alad [1] filed a deletion request for spinach [2]: > > > > > > Antiquated yaourt clone, sources PKGBUILDs for dependency resolution > > > before users can inspect them. Otherwise no unique functionality. > > > > > > [1] https://aur.archlinux.org/account/Alad/ > > > [2] https://aur.archlinux.org/pkgbase/spinach/ > > > >
