Eliminate user@ portion of ssh codehosting URLs

Bug #137910 reported by Jonathan Lange
4
Affects Status Importance Assigned to Milestone
Launchpad itself
Medium
Tim Penhey

Bug Description

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".

Revision history for this message
Jonathan Lange (jml) wrote :

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.

Changed in launchpad-bazaar:
assignee: nobody → jml
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Tim Penhey (thumper) wrote :

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.

Revision history for this message
Andrew Bennetts (spiv) wrote :

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.

Revision history for this message
Jonathan Lange (jml) wrote :

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.

Changed in launchpad-bazaar:
assignee: jml → thumper
status: Confirmed → Incomplete
Revision history for this message
Andrew Bennetts (spiv) wrote :

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.

Revision history for this message
Jonathan Lange (jml) 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.

Revision history for this message
Andrew Bennetts (spiv) wrote : Re: [Bug 137910] Re: Eliminate user@ portion of ssh codehosting URLs

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).

Revision history for this message
Tim Penhey (thumper) wrote :

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

Changed in launchpad-bazaar:
milestone: 1.1.10 → 1.1.12
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I guess we should think about this soon then.

Tim Penhey (thumper)
Changed in launchpad-bazaar:
milestone: 1.1.12 → 1.2.1
Tim Penhey (thumper)
Changed in launchpad-bazaar:
milestone: 1.2.1 → 1.2.2
Tim Penhey (thumper)
Changed in launchpad-bazaar:
milestone: 1.2.2 → 1.2.3
Revision history for this message
Christian Reis (kiko) wrote :

What's incomplete about this bug?

Revision history for this message
Jonathan Lange (jml) wrote :

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.

Tim Penhey (thumper)
Changed in launchpad-bazaar:
milestone: 1.2.3 → 1.2.4
Jonathan Lange (jml)
Changed in launchpad-bazaar:
milestone: 1.2.4 → none
Jonathan Lange (jml)
Changed in launchpad-bazaar:
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers