[aur-requests] [PRQ#9551] Deletion Request for spinach
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/
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. 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 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 from a local directory of PKGBUILDs. Since I haven't used all of them I don't really know how it compares to everything out there. Not saying it's the greatest, but I think it has uses. 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/
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/
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/
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.
You're running executable code in the hopes that you've covered every possible case with an adhoc filter. That fits the definition of "risk" pretty well.
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.
When I filed the request I was looking at the git history, with the latest commit in 2014 (that's long before AUR 4). Since you as the author are ostensibly still alive, I've filed an issue with possible implementations: https://github.com/floft/spinach/issues/2
I guess calling that risky is fair. I have not adequately shown that this covers every possible case. If I was great at formal verification, I could attempt to prove that. Albeit, that would be more work than just using a better method. I viewed this as essentially escaping input. For example, in HTML it is sufficient to escape something like 3 symbols. Here's the filter: cat | sed -r 's/\$\([^)]+\)//g s/`[^`]+`//g s/;.*//g' Though, there are some filters that I would not view as risky (provided sed does exactly what the regular expression states): cat | sed -r 's/.*//g' Maybe a whitelist approach would have been better. In any case, I went with the Bash code you provided. Thanks for the bug report. Fixed. On Wed, Oct 25, 2017 at 1:55 AM, Alad Wenter <alad@mailbox.org> wrote:
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.
You're running executable code in the hopes that you've covered every possible case with an adhoc filter. That fits the definition of "risk" pretty well.
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.
When I filed the request I was looking at the git history, with the latest commit in 2014 (that's long before AUR 4). Since you as the author are ostensibly still alive, I've filed an issue with possible implementations:
Request #9551 has been rejected by Alad [1]: Package was updated. Thanks. [1] https://aur.archlinux.org/account/Alad/
participants (3)
-
Alad Wenter
-
Garrett
-
notify＠aur.archlinux.org