[conkeror] Re: Protocol handling bug?

  • From: Philip Hudson <phil.hudson@xxxxxxxxx>
  • To: Florian Bruhin <me@xxxxxxxxxxxxxxxx>, conkeror@xxxxxxxxxxxxx
  • Date: Tue, 5 Sep 2017 17:09:37 +0100

And now, after quitting and restarting Conkeror, the protocol handler
works as expected, invoking the shell script with the correct single
parameter.

This makes me think that there is an issue with Conkeror's M-x load
and the specific file with my protocol handler code (I have multiple
numbered files under a .conkerorrc directory, rather than a single rc
file).


On 3 September 2017 at 21:41, Philip Hudson <phil.hudson@xxxxxxxxx> wrote:

On 3 September 2017 at 21:07, Florian Bruhin <me@xxxxxxxxxxxxxxxx> wrote:
Hi,

(first of all, I'm not using conkeror, but I felt like I could maybe
answer this anyways)

Thanks Florian.

On Mon, Aug 28, 2017 at 02:56:58PM +0100, Philip Hudson wrote:
According to log output, it seems that the URI passed to an executable
file specified as the protocol handler for that URI's scheme is not
shell-quoted. Thus, if the URI contains a query string, delimited by
'&' characters as such strings inevitably are, the shell decides that
it is being told to background a command, and the rest of the URI is a
new command (which itself may be demanding to be backgrounded, etc
etc).

Mozilla code, I think, not "our" code.

This seems so incredible that I wonder if there's something I've
missed. Surely this can't have gone undetected and uncorrected this
long?

The example on the wiki of a protocol handler for 'magnet' scheme URIs
can never have worked if my reasoning is correct, since 'magnet' URIs
pretty much always contain long multi-part query strings. Can anyone
contradict that? Anyone got that example working? I'm using a shell
script rather than the Transmission binary specified in the wiki
example. Surely that should not make a difference?

Why would it ever be passed to a shell? I haven't checked this in case
of Firefox/conkeror, but usually, when you configure an application to
open something with in some other applications, a shell is never
involved, it just uses an exec syscall to invoke the configured
application directly.

I don't know why, but it does, according to my log output. I also
wondered about this. It does seem strange.

Even if you start a shell script that way (assuming it has e.g. a
#!/bin/bash shebang and you configure the script as handler directly),

#!/usr/bin/env bash, to be precise. The script is indeed configured as
handler directly.

it should simply get the URL as an argument, as a string.

... but in that "it should get" lies the problem.

How, if not via invocation of a shell? I think that's where the problem is.

Conkeror (or rather Firefox/xulrunner) must be invoking a shell with
-c, passing the script name as the shell's arg 0 (as you would expect)
and the _unquoted_ URI intending it to be arg 1. Of course, according
to shell syntax, the URI, with its multi-part query string, parses as:

arg 1 &; arg 0 &; arg 0 &; arg 0 &; arg 0

(Just without the spaces and semicolons).

Seems brain-dead stupid to me, if that really is the case. As I said,
I can't believe this could possibly have gone unnoticed all this time.

As long as you
don't call something like eval - a common misspelling of evil ;) - on
it, it should never be interpreted as something for the shell to
execute.

No eval. I'd be too ashamed to ask anyone for help with something that
called eval. :-)

--
Phil Hudson                  http://hudson-it.ddns.net
Pretty Good Privacy (PGP) ID: 0x887DCA63



-- 
Phil Hudson                  http://hudson-it.ddns.net
Pretty Good Privacy (PGP) ID: 0x887DCA63

Other related posts: