Re: [PATCH] Add shell-quasiquote.

[taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer)]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> "John Wiegley" <johnw@newartisans.com> writes:
>
> [...]
>
> For those interested in this topic, please also read my response to
> another mail by John on the bug#21702 thread.  I'm afraid there was a
> big misunderstanding in, at least, the reasons for my frustration.
>
> I don't know whether the points mentioned above (people being used to
> *faster* paced communication than e-d) apply to other cases of
> contributor frustration, but I suspect that it's a red herring.
>
> Taylan

Err, silliness, John took that discussion off the bug ML (sensibly).

Long story short, the problem is far from unresponsiveness.  The problem
is giving me the feeling that no matter how many times I raise the same
point on why I need a given change in shell-quote-argument or else
cannot use it, no matter how clearly I strain myself to explain the
logic, and even provide patches that address the issue, my points get
outright ignored, misunderstood (willfully?), irrelevant points raised
out of nowhere to argue against, the patches of course not used, and so
on and so forth.  All the while I get bluntly commanded to make a change
to my code that goes directly against the point I'm trying to raise the
whole time.

There is not a dismissive attitude towards my work altogether, but to my
very words and ideas.  I'm not a brainless code-editing machine to
follow the orders of emacs-devel, so if I point out a reason why I don't
want to make a given change, listen to it.  If I even propose a solution
that will make me able to make the given change, and even offer a patch,
actually consider it.


To elaborate...

In the first mail in this thread already, a function of mine which did
precisely what the documentation implied, and did that correctly, has
been outright called "wrong," and I was more or less commanded make a
change to my code for which there was a comment indicating that I
already considered the change and intentionally decided against it.  You
would expect some respect to one's intellect, therefore a simple request
of clarification or such if the reason for my decision is unclear, but
nope:

>> +;;; Like `shell-quote-argument', but much simpler in implementation.
>> +(defun shqq--quote-string (string)
>> +  (concat "'" (replace-regexp-in-string "'" "'\\\\''" string) "'"))
>
> It might be simpler, but it's wrong, because the result is only
> correct for Posix shells.
>
> Please do use shell-quote-argument instead.

(The documentation for the whole library mentioned that only POSIX is
supported, although not that comment.)

Not thinking much about it (this level of unintentional impoliteness is
daily course), I ignored that mistake in attitude, and briefly explained
the reason for not making the change outright:

> Hmm, I don't really want to take responsibility of my library being used
> with shells other than POSIX shells.  (The library could make that
> clearer and error on other systems.)

> How much can I rely on shell-quote-argument?  Can one fully rely on it
> being safe against code injection?

After that I was asked what sort of code injection I mean, which I
clarified.  I also clarified that I don't want to take responsibility of
my code being used on other systems, but that it's no problem if the
responsibility can be shared:

> I generally don't want to take responsibility of my code being used on
> non-GNU/non-POSIX systems, but if I can share the responsibility then
> that's fine.

> (let ((file-list (read where-ever)))
>   (shqq (cp -- ,@file-list some-place)))
> 
> That code is *guaranteed* to either copy the files in file-list to
> some-place, or error, so long as the argument quoting by shqq works
> well.  If it has a bug, then malicious input from where-ever may be able
> to execute arbitrary shell commands.
> 
> Is shell-quote-argument safe against such a thing?  My shqq-quote-string
> isn't exactly formally proven to be safe either, but its implementation
> is so simple it's fairly obvious that it doesn't contain bugs.

This was responded to with an assertion that I somehow share
responsibility over the whole Emacs code-base.  And more or less an
outright dismissal of the problem I explained:

> Please take a look at the implementation of shell-quote-argument.  It
> uses the same interfaces as your implementation, no more, no less.  If
> your implementation is safe, then so is shell-quote-argument.

(Which "interface"?  The two implementations differ entirely.  Was
"interface" meant as in function signature?  How is that relevant to
implementation quality, and what's the problem with clearly documenting
the safety guarantees offered by the interface?)


I could go on, but you're probably bored.  After that point, more people
join in with careless assertions that shell-quote-argument is surely
safe and can be relied on, shortly after which someone demonstrates an
injection attack on it when used with csh.  Even that doesn't convince
our folks, and an abrasive and dismissive attitude towards the problem
I'm pointing out continues.  The same thing repeats/continues on the bug
mailing list.

I feel kind of silly writing this mail, because it doesn't amount to
much more than rehashing what's already found few mails up in the
archive.  I can do little better than pointing and asking "don't you see
the problem here?!"

But maybe some people will look harder now, I hope.


And before someone thinks of making a nasty remark about over
sensitivity, feelings of entitlement, or else, I'd like to point out
that my frustration is rooted in part in people's unwillingness to
accept the importance of a code injection vulnerability.  And that's a
technical point.  It's precisely because I *don't* believe that Emacs
developers are idiots (as was suggested at some point) that I believe
the problem must instead have some social/behavioral aspect to it, like
a fundamental lack of belief in newcomers' ability of insight, or lack
of care in explaining why you think a mentioned problem is in fact not a
problem, or something of that sort.

Taylan