[MERGE][#109143] Support bzr+ssh://host/~/path

[Andrew Bennetts]

Martin Pool wrote:
[...]
> 
> It would be great to have that feature.  But if you're implementing it
> by changing the ssh invocation method, then that does seem a bit
> problematic: it may cause problems with configurations that check the
> command, as you say, and it also means it won't work if bzr+ssh is
> invoked over something other than ssh.

I don't understand what you mean by “if bzr+ssh is invoked over something
other than ssh”.  Perhaps you mean “other than /usr/bin/ssh from OpenSSH”,
but if so I don't understand why you think that would be a problem?

I don't think the server configuration issue such a big issue in practice.
First, no existing URLs will break, unless people really were depending on
accessing a directory called “~” in the root of the remote filesystem!  So
it's not going to cause any regressions.

Also, many sites don't restrict; it's just ordinary user accounts that can
run arbitrary commands.  These are really the primary use case for /~/.

Finally, if there is a restriction, it's typically for a setup like
python.org's, to lock-down an SSH account to only run bzr.  If you are doing
that, then your server is probably configured to run bzr with
--directory=/path/to/code anyway.  In that case the client wouldn't have any
reason to use /~/ URLs, as they are already using URLs like
bzr+ssh://pythonbzr@code.python.org/python/3.0 (which is an actual URL from
http://wiki.python.org/moin/Bazaar).

I'm not sure of the exact details of how python.org configured that, but if
they did it by specifying a command="..." option in OpenSSH's
authorized_keys, then whatever command the client tries to run is ignored
anyway.  (Also, the command the server unconditionally runs can inspect
SSH_ORIGINAL_COMMAND if it really wants to behave differently for
--directory=. vs. --directory=/)

FWIW, I'm fairly sure bazaar.launchpad.net's SSH server will be easy to
adjust.

So in short:

  * all existing bzr+ssh:// URLs will keep working.
  * servers with a restricted configuration probably don't benefit from /~/
    URLs (because the server already overrides --directory), so users won't
    use them there.
  * if a server has a restricted configuration *and* wants to vary behaviour
    according to the requested --directory, OpenSSH gives them
    straightforward tools to do that.

So I don't believe it's actually problematic at all.

> Could we perhaps instead have either file:///~mbp/foo expand properly,
> at least optionally, and then have the server look them up?

I'm not sure what you're proposing here.  How does a file:/// URL help me as
a user avoid typing /home/andrew in my bzr+ssh:// URLs?

Oh, I think I see what you have in mind.  Presumably the server internally
generates file:///~mbp/foo when the client asks for ~mbp/foo via the smart
protocol (there's a ChrootTransport between the client and the remote's
LocalTransport, but it doesn't matter to this discussion), so you're
proposing that the LocalTransport should expand file:///~mbp to
file:///home/mbp on the server.

I suppose that's an option, although changing how we handle file:/// URLs
makes me nervous.  We'd also lose the neat correspondence with sftp:// URLs,
which AIUI don't expand ~mbp, just ~.

-Andrew.