bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#19350: #19350 24.4; Incorrect quoting of %-signs for Windows command


From: Demi Obenour
Subject: bug#19350: #19350 24.4; Incorrect quoting of %-signs for Windows command shell
Date: Thu, 11 Aug 2016 19:11:44 -0400

I think that this needs to be fixed 100% — it is a security issue.

Another option is to enable command extensions every time Emacs spawns a shell.

On Aug 10, 2016 9:00 AM, "Noam Postavsky" <npostavs@users.sourceforge.net> wrote:
>
> tag 19350 confirmed
> severity 19350 minor
> quit
>
> > Looking at the code in subr.el, it is clear that Emacs mishandles
> > %-signs when escaping for the Windows command interpreter.
> [...]
> >
> > I deleted the lossage from the report, as there is no point in including
> > it, this being a logic error in subr.el. In fact, the buggy code is dead
> > on my machine (I run Linux) -- I happened to know about the problem on
> > Windows.
>
> Well, it would have been nice to mention which function you're talking
> about, and give an example problematic string.  I guess it's
> shell-quote-argument:
>
> Evaluating
>
> (let ((process-environment (cl-list* "ca^=with-caret"
>                                      "ca=without-caret"
>                                      process-environment)))
>   (insert (shell-command-to-string
>            (format "echo %s %s %s"
>                    "%ca%"
>                    (shell-quote-argument "%ca%")
>                    "%%CD:~,0%ca%%CD:~,0%"))))
> gives
>
> without-caret "with-caret" %ca%
>
> On the other hand, this is such an obscure corner case, I'm don't know
> if it's even worth fixing.
>
> > A method of handling % that I believe to be fully
> > robust is to follow (not precede) each series of % characters with
> > %CD:~,0%. This is an expansion that always expands to the empty
> > string. It will work provided that:
> >
> > * Command Extensions are enabled.
>
> I'm not sure if Emacs can assume this.
>
> >
> > * It is not possible for cmd.exe to interpret an environment variable
> >   whose name is the empty string.
>
> I found that adding "=emptyvar" to process-environment caused
> "Spawning child process: exec format error", so I guess this
> assumption is safe.


reply via email to

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