[aur-requests] [PRQ#9551] Deletion Request for spinach

[Garrett]

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

> > Garrett <garrett.floft at 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 at 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/
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.archlinux.org/pipermail/aur-requests/attachments/20171024/6fc3d794/attachment.html>