bzr+ssh broken for non standard ports.

Bug #146715 reported by James Westby
4
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
High
Andrew Bennetts
bzr (Debian)
Fix Released
Unknown

Bug Description

Fixing bzr log bzr:// caused the following regresion going from 0.91rc2 to 0.91.

I have a few bzr+ssh:// repositories hosted on a remote server. In
order to isolate different classes of users from one another, they are
stored in vservers, and each vserver has an SSH daemon listening on a
different port (10022, 20022, etc.). My ~/.ssh/config has entries so
that the right port is automatically selected by ssh when connecting
to the appropriate CNAME.

bzr 0.91rc2 used to work fine, but 0.91 final explicitly adds a "-p
22" to the SSH invocation, thus overriding the configuration and
breaking bzr+ssh:// branches with non-22 ports. I believe this
regression may be related to the following paragraph, listed in "BUG
FIXES" of the NEWS.gz file:

   * Fix ''bzr info bzr://host/'' and other operations on ''bzr://' URLs with
     an implicit port. We were incorrectly raising PathNotChild due to
     inconsistent treatment of the ''_port'' attribute on the Transport object.
     (Andrew Bennetts, #133965)

Roland.

Thanks to Roland for the report.

Changed in bzr:
status: Unknown → New
Revision history for this message
Martin Pool (mbp) wrote :

That is likely to be the problem.

Changed in bzr:
importance: Undecided → High
status: New → Triaged
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

This bites attempting to test the launchpad code hosting server locally. It's very annoying.

I'm not sure I understand the motivation for the change that introduced this bug though...

Revision history for this message
Andrew Bennetts (spiv) wrote : Re: [Bug 146715] bzr+ssh broken for non standard ports.

I guess we have the same problem with sftp:// URIs now too. Although I think
technically URIs aren't supposed to be dependent on local configuration; if the
URI doesn't specify a port it then the standard port for that protocol should be
assumed. See e.g.
<http://tools.ietf.org/html/draft-ietf-secsh-scp-sftp-ssh-uri-04>.

Anyway, in practice though this isn't what people expect for SSH transports,
because they're used to configuring aliases in ~/.ssh/config, so we probably
should just do what they expect.

So I guess we need to treat “port not specified” differently to “port is 22” for
sftp:// and bzr+ssh:// transports. (Taking care not to reintroduce bug 133965,
of course, which was fixed by treating those the same for all transports with
ports.)

I've got a branch that fixes this by simply not setting “default_port” for
bzr+ssh or sftp, I'll send it to the list shortly.

 assignee <email address hidden>

Changed in bzr:
assignee: nobody → spiv
Revision history for this message
Jonathan Lange (jml) wrote :

We couldn't reproduce this problem with sftp.

Including the port number in the URI seems to work around this bug.

Revision history for this message
Andrew Bennetts (spiv) wrote : Re: [Bug 146715] Re: bzr+ssh broken for non standard ports.

The fix is now on the list, awaiting review.

 status fixcommitted

-Andrew.

Changed in bzr:
status: Triaged → Fix Committed
Revision history for this message
Martin Pool (mbp) wrote :

fixed in 0.92

Changed in bzr:
milestone: none → 0.92
status: Fix Committed → Fix Released
Changed in bzr:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.