"there's a hidden eval every time you use shell arithmetic." -- http://www.oilshell.org/blog/2019/06/17.html#toc_6
% echo $((x+1))
% echo $PATH
@akkartik It is a very explicit eval via a subshell. There should be no surprise here other than users can't recognize subshells :)
"..things that can be parsed as variable names are treated as variable names in arithmetic contexts. ..bash does this *recursively* until it gets to an integer, or to something that can't be parsed as either an integer or a variable name."
OMG. This is _not_ documented.
@rain @kingcons @akkartik If a webapp is building a string to send to any shell, even this S shell, it is already susceptible to shellshock-like attacks since it is by definition building a string that will be evaluated. The only protection against this is if the language the webapp is using has proper shell string building library that handles escaping properly, like most have to SQL et al.
@rain @alcinnz @gcb @kingcons @akkartik So the original method uses escaped plaintext queries. But at some point someone figured out that they could parse a symbolic version of a query, save that parsed version, and then provide non-escaped arguments to that pre-parsed query, which is both faster (for complex queries) and much safer. I have no idea what the protocol looks like for this but I assume it has explicit string lengths or null terminators or something, instead of quoting.
yes it seems to be quite nice and simple the way it works and basically parameters are sent as something similar to netstrings.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!