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 <alad@mailbox.org> wrote:

> Garrett <garrett.floft@gmail.com> 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, <notify@aur.archlinux.org> 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/
> >