emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add shell-quasiquote.


From: Taylan Ulrich Bayırlı/Kammer
Subject: Re: [PATCH] Add shell-quasiquote.
Date: Sun, 18 Oct 2015 00:45:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Random832 <address@hidden> writes:

> address@hidden (Taylan Ulrich "Bayırlı/Kammer") writes:
>
>> Dmitry Gutov <address@hidden> writes:
>>> If you know of a real problem scenario reproducible with
>>> shell-quote-argument, please file a bug. Then we'll fix it.
>>
>> Not knowing that there are bugs is not proof that there are no bugs.
>
> Why aren't you as sure of its safety, regarding the POSIX section, as you
> are of the safety of your implementation?

I was probably being overly pedantic on that one, but if \<newline> has
a semantics other than resulting in a literal newline, I thought maybe
some other \<character> sequences might also have different semantics.
With different kinds of whitespace and all.

>>> Either way, please avoid reinventing the wheel.
>>
>> It's not a reinvention because it has very strict semantics with regard
>> to safety guarantees, which shell-quote-argument apparently doesn't.
>
> Out of curiosity, how are you guaranteeing that the result will be
> executed by a POSIX shell? Passing a string quoted by your function to
> MS Windows' cmd.exe (or, to that matter, to csh - even worse than the
> existing version) would be an absolute disaster as far as injection
> vulnerabilities go.

I'm afraid there's no way for my library to mechanically prevent that,
since the library only outputs commands as strings.  (So the user can
pass it to shell-command, async-shell-command, shell-command-on-region,
or anything else.)

Though it would have been best to be able to prevent such mistakes
mechanically, I hope having it in the first two sentences of the
documentation is good enough. :-)

Taylan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]