Bazaar Explorer crash on qconfig when using checkouts via bzr+ssh

[Maritza Mendez]

On Sun, Sep 26, 2010 at 11:56 AM, Vincent Ladeuil
<v.ladeuil+lp at free.fr<v.ladeuil%2Blp at free.fr>
> wrote:

> >>>>> Maritza Mendez <martitzam at gmail.com> writes:
>
>    > On Sun, Sep 26, 2010 at 9:25 AM, Maritza Mendez <martitzam at gmail.com>
> wrote:
>    >> If this bug has been reported, I failed to find it on Launchpad.
>
> Very nice bug report, please, don't hesitate to file it on
> launchpad. Anyway, failing to find a duplicate is not a deadly sin ;)
>
> At worst, the community or the devs may finally realize it's a dupe but
> could point to it if the report is clearer or better explain the
> problem.
>
>    >> There have been numerous "TooManyConcurrentRequests" bugs filed,
>    >> but most/all of them seem to be related to legitimate attempts to
>    >> open an ssh connection.  I have found a case in which there seems
>    >> to be no legitimate reason to involve ssh.
>
> Even if the reason is not legitimate, it's still possible that we
> shouldn't tracebak and create a new connection (I'm pretty sure we have
> related and valid use cases that we fail to handle (and we raise
> TooManyConcurrentRequests), http:/pad.lv/483661 for example. There is
> also one use case I thought I reported but couldn't find anymore :-/
>
> <snip/>
>
>    >> So it *appears* that either qconfig or explorer is triggering an
>    >> illegitimate ssh connection request when the active GUI page is a
>    >> checkout via bzr+ssh.
>
> In fact, that's the opposite that is surprising: that we manage to resue
> the same connection instead of creating a new "illegitimate" one. Trying
> to use the same connection is "illegitimate", hence the exception. But
> *why* we are doing this, is unclear.
>
> <snip/>
>
>    > FYI, it does not matter if the checkout was set up exactly as
>    > above or if I use authentication.conf to minimize typing.  As it
>    > turns out, I usually need to include the username in the transport
>    > scheme anyway because I use several different "shared" accounts on
>    > the server to grant access to different groups of branches.  It's
>    > a simple but effective way of controlling access to "restrcited"
>    > repositories.
>
> This sounds interesting, would you mind share your setup (if only in
> describing it a bit more) and tell us what is missing in the crontrib/
> directory or if you used or modified something here ?
>
>          Vincent
>


Thanks for your support.  A few quick notes:

1. The bug is now logged as
https://bugs.launchpad.net/bzr-explorer/+bug/648294

2. I appreciate the irony.  (A month ago I suggested that tools in the bzr
system should reuse ssh connections).  I'm impressed that you remembered and
more impressed that you pointed this out so gently.  :)

3. Regarding access control, I didn't have to modify anything (although I
admit to having thought about it).  I have a box which I use to provide
centralized storage for bzr branches for use by (at least) two teams, who
are working on two different, but not necessarily disjoint sets of code.
Suppose Team1 is working on Product1 and Product2.  Team2 is working on
Product1 and Product3.  So both teams need to access branches related to
Product1 and but only Team1 should see Product2 and only Team2 should see
Product3.  So I create three users on my central server: user1 who owns
Product1 branches, user2 who owns Product2 brnaches and user3 who owns
Product3 branches.  Team1 is given passwords for user1 and user2.  Team2 is
given passwords for user1 and user3.  Now the beauty of bzr+ssh is that each
member (of Team1 or Team2) only needs to use a given password once -- to
store her SSH public key in each account for which she has a  password.
After that, an ssh-agent takes care of the rest.  This system is relatively
each to maintain *unless* you need to revoke someone's access to a
particular branch.  To do that, you have to change the password of the
"shared user" which owns that branch.  And that inconveniences everyone who
uses that "shared account" for any branch it owns.  So this works for small
setups but I would not try to use it in a large enterprise.  Another thing
to remember obviously is this setup does nothing to stop a developer from
improperly disclosing her legitimately obtained branch to unauthorized
people.  But then that's always the case with all information.

~M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20100926/bb748ef0/attachment-0001.htm