Eliminate user@ portion of ssh codehosting URLs

[Jonathan Lange]

We don't need the user@ portion of the bzr+ssh (or sftp) URL, given that we are be presented with the public key. We can use the public key to work back to the user.

Thus: bzr+ssh://bazaar.launchpad.net/~/firefox/foo would mean "my personal branch of Firefox called foo".

[Jonathan Lange (jml)]

SSH sends a user name as part of the authentication request. Need to figure out a sane way of handling a mismatch between the given user name and the inferred user name.

[Tim Penhey (thumper)]

What about getting people to confirm their SSH keys.

If we had a flag that specified that the key had been verified, then we could use the inferred user name based on the key, but if it hadn't been verified then we'd use the SSH supplied user name.

[Andrew Bennetts (spiv)]

TIm, I don't understand your comment. Are you proposing that users would have to explicitly mark their public keys in launchpad with a flag meaning "ignore the SSH user name if authenticating against this key"? That would seem to lose most of the intended benefit of this change, which I understand to be the Just Works convenience. If you need to configure something somewhere, then we may as well keep the status quo, which at least doesn't require special logic on our side, and doesn't require our users to learn a unique way of configuring things that applies only to Launchpad.

That said, I'd be a little sad to have this feature at all, as we'd lose the trivial mapping of private URLs to public URLs just by changing "bzr+ssh" to "http". Also, if dealing with long URLs and/or repositories with many branches is a UI problem, then it'd be good to find a solution in Bazaar directly, so that all Bazaar users, even those working on local paths or with non-Launchpad hosts, could benefit from it.

[Jonathan Lange (jml)]

I think that rather than working on eliminating user@ from bzr+ssh URLs, we should be working on switching the webapp to refer to lp:/// URLs and making sure that lp:/// URLs DTRT.

Andrew, note that bzr+ssh URLs are not "private", they work for anyone for any branch (as long as you have an SSH key registered on Launchpad).

Re-assigning this ticket to Tim, for him to invalidate.

[Andrew Bennetts (spiv)]

Yeah, "private" was a poor choice of term. I meant "private" in the sense of "personal"; i.e. the URL I would use to access my branch would become significantly different to the URL others would use for the same branch.

I much prefer the lp:/// idea.

[Jonathan Lange (jml)]

That's the sense I took from the term. You can use bzr+ssh URLs to access any branch — thus others use the same URL as I do to access my branches.

[Andrew Bennetts (spiv)]

Jonathan Lange wrote:
> That's the sense I took from the term. You can use bzr+ssh URLs to
> access any branch — thus others use the same URL as I do to access my
> branches.

Not if the URL changes to be bzr+ssh://bazaar.launchpad.net/~/foo/bar
though...

(And also this isn't currently true of SFTP last I checked, although I
realise SFTP is somewhat deprecated by now).

[Tim Penhey (thumper)]

Work on lp: URIs for bzr is in progress. We'll see if this is still a priority towards the end of the year.

[Michael Hudson-Doyle (mwhudson)]

I guess we should think about this soon then.

[Christian Reis (kiko)]

What's incomplete about this bug?

[Jonathan Lange (jml)]

We aren't sure whether we want to do it.

Eliminating the user@ portion of the URL means determining the user based on one of the SSH keys that they offer in the authentication step. This seems distasteful:

  1. We'll be necessarily ignoring the user name that the user sends over SSH.
  2. It's very similar (perhaps equivalent?) to just asking the user for a password, and then inferring the username from that. The differences are that SSH keys are longer and we'll have a uniqueness constraint on SSH keys.

Making '~/project/branch' be a short-hand for '~username/project/branch' is more attractive, although spiv raises valid concerns about how it breaks consistency with HTTP.