On 26Jun2020 09:17, Kevin J. McCarthy <[email protected]> wrote:
>On Fri, Jun 26, 2020 at 12:49:41PM +0200, Oswald Buddenhagen wrote:
>>On Thu, Jun 25, 2020 at 03:54:24PM -0700, Kevin J. McCarthy wrote:
>>>Is it worth correcting this?
>>>
>>yes, doing parsing and quoting in the right layers is important.
>>failure to do so leads to insanity and security holes.
>>but make sure to check *all* consumers, lest you actually
>>(re-)introduce security holes (if the handling of some untrusted
>>data relies on this weird quoting behavior).
>
>Thanks Oswald. I'll take a closer look at this.
>
>One thing I can do is keep the escaping *only* for the cases it might
>be needed, such as hook command extraction.
I am for removing _all_ the escaping. Anything that mangles the values
in variables should be removed - it only makes for unreliable behaviour.
I there's a _real_ use for escaping (hmm, what _kind_ of escaping? shell
compatible quoting?), I'd rather provide a mechanism for doing that than
have subtle/obscure special cases.
As an allegory, I have various shell scripts which issue remote commands
via ssh, or construct small shell commands. My ritual is typically
something like this:
dirpath=$1
.....
# explicitly quote the string
qdirpat=$( shqstr "$dirpath" )
# now construct a shell command
shcmd="mkdir $qdirpath"
......
That would be tedious and painful in mutt, but what if there were
implied variables?
setting='some value'
$shq_setting ==> quotes/escaped value of $setting
Another example: I've got a Python tagging library like this, whose
python-format-string mode has implied values. So, if I've got a "title"
value I can use {title} in a format string to get the title, or
{title_lc} for the downcased-and-dashed form (often constructing
filenames here).
So in this example the magic suffix _lc implies that operation.
Basicly I'm suggesting "virtual" variables computed from existing
variables. It would solve a number of horrible "I'm nesting quoting"
situations too.
Thoughts?
Cheers,
Cameron Simpson <[email protected]>
