[PATCH] Teach Mercurial to handle URLs of the form *sh://host/path, such as

[peter.kourzanov at xs4all.nl]

  So, what's the difference between saying rsh://host/path and saying
--ssh=rsh ssh://host/path? Somehow, I find the first one less ugly and
more explicit (at least, you see what the protocol is immediately,
rather that seeing just an ssh:// there which could actually still mean
anything else than ssh depending on some obscure configuration option in
some configuration file).

On Wed, May 21, 2008 at 05:04:10PM -0500, Matt Mackall wrote:
> 
> On Wed, 2008-05-21 at 12:54 +0200, Pjotr Kourzanov wrote:
> > What if you specifically need to use certain options for ssh (the 
> > ssh), such as -1 or -2 or whatever. Isnt't it just easier to create a 
> > wrapper called ssh1 or ssh2 and just use e.g., ssh1://host/path? What
> > if you need to push/pull to/from sites that accept only ssh1 or ssh2?
> > Do you want to constantly change your ui.ssh config or complicate the
> > command line with -e?
> 
> ssh1 is of course another bad example as the protocol has been
> completely broken. But even in this case, you would simply add this as a
> setting to .ssh/config for the odd hosts that uses ssh1, and not mess
> with hg's config at all.
> 
> >   My stake in this patch is that in a large project/organization, you
> > can simply start using a krb5-rsh:// URLs and it will just work, while
> > without it, you'd have to globally change out-of-the box configuration
> > of Mercurial such that everyone uses ui.ssh=krb5-rsh. Oh yes, don't tell
> > me the story of SSH public keys dispersal through a large company. It's
> > just so much simpler with Kerberos - do a /usr/bin/kinit once and you're
> > authenticated - no need for any public key transfers...
> 
> And if you were using a modern ssh with Kerberos support built in, you'd
> a) be even safer [1] and b) have no config issues.

  I do;-) The problem is that not all client/server hosts do (think corporate
server setups with whatever UNICES on them). The krb5-rsh clients and servers 
are however pretty much standard in those environments...

  Somehow, I find a lot of value in packages that always work
out-of-the box without me spending days on tweaking/compiling the
autoconf-ed hell out of open-source projects...

> 
> >   OK, here I stop and simply wonder why such a small and useful 
> > generalization is so difficult to get in...
> 
> - it adds an infinite non-standard protocol namespace
> - some parts of which will act bizarrely (eg bsh://)

  The same goes for --ssh and ui.ssh. Who checks that --ssh and ui.ssh
actually specify an ssh protocol handler?

> - the infinite namespace doesn't even cover everything (eg dropbear)

  OK, that's the only good use for --ssh and ui.ssh.

> - it's a bit ugly
> - the use cases are unusual/silly enough to not be very convincing

  That may be (that I'm the only one using the Kerberos rsh out there,
but heck, I do find it much more useful and agile than ssh within my 
environment).

> 
> [1] http://www.cs.berkeley.edu/~hildrum/043.pdf
> 
> -- 
> Mathematics is the supreme nostalgia of our time.
>