<div dir="ltr"><div>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:<br></div><div><div><div><br></div><div>cat | sed -r 's/\$\([^)]+\)//g</div><div>s/`[^`]+`//g</div><div>s/;.*//g'</div></div><div><br></div><div>Though, there are some filters that I would not view as risky (provided sed does exactly what the regular expression states):</div><div><br></div><div>cat | sed -r 's/.*//g'</div><div><br></div><div>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.</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 25, 2017 at 1:55 AM, Alad Wenter <span dir="ltr"><<a href="mailto:alad@mailbox.org" target="_blank">alad@mailbox.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> However, I at present do not believe spinach is "risky." It does not source<br>
> the PKGBUILD directly. I do not think it will allow arbitrary code<br>
> execution before viewing unless there is a method for executing code in a<br>
> string in Bash other than with tick marks or $(...). I would easily be<br>
> convinced that it is risky if I could find such an example. Note that such<br>
> things are listed in a security section in the man page. Though, as you<br>
> said, I could (and should) change this fairly easily to use a more modern<br>
> method.<br>
><br>
</span>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.<br>
<span class=""><br>
> In my view this discussion might be more suited as a bug report for spinach<br>
> rather than a cause for deleting the package, but delete it if you wish.<br>
><br>
</span>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:<br>
<br>
<a href="https://github.com/floft/spinach/issues/2" rel="noreferrer" target="_blank">https://github.com/floft/<wbr>spinach/issues/2</a><br>
</blockquote></div><br></div>