bzr.dev <-> bzr.dev network api break

[Daniel Silverstone]

On Mon, 2008-01-21 at 09:48 -0600, John Arbash Meinel wrote:
> People keep saying this... and I have to disagree each time. bzr_access 
> *doesn't* let you control access on a per-remote-repository basis. But 
> it *does* let you control read versus write through the same ssh-user 
> for multiple ssh keys.

That's not what the script nor its configuration file implies.

> I honestly don't think we can do better at the ssh level anyway, just 
> because we don't *know* where the repositories is going to be versus the 
> branch we are trying to connect to, versus the file inside the branch. 
> (bzr log http://bazaar-vcs.org/bzr/bzr.dev/bzrlib/lru_cache.py)

Hence the work needs to be inside bzrlib somewhere.

> That said, I think there is merit in having the ability to control 
> access on a subdirectory/per repository basis. Which is why I put up the 
> blueprint for it. I think it is possible to do without having to involve 
> the smart transport at all. And at least for now, I'm not really keen on 
> layering authentication on top of transports that already provide 
> authentication.

Fair enough, authentication is perhaps the wrong term. Perhaps, leaving
authentication to the access method, bzrlib needs to have some form of
authorisation support inside itself or supplied alongside itself? Even
if it's a smart-protocol proxy which can filter and adjust based on
verbs it sees pass through such as the open_bzrdir(?) operation.

I think bzr_access is meant more as an authoriser than an authenticator
since SSH itself has done the authentication, but as you say, in its
current form, all it can do is choose between RO or RW based on key, not
based on key-accessing-given-repo-or-branch which is what anyone looking
to migrate from SVN would want.

The reason I'm interested in this is because my partner recently was
convinced to move to bzr from svn, but he continues to bemoan the lack
of ability to control easily who can read/write from his selection of
projects. I attempted to use the wscgi interface as a FastCGI but that
seemed to go down like a lead balloon because I couldn't even get
trivial read-only access to work for that on my own branches.

I shall take a look at the blueprint you registered which I assume is
acl-transport.

Thanks,

Daniel

-- 
Daniel Silverstone                         http://www.digital-scurf.org/
PGP mail accepted and encouraged.            Key Id: 2BC8 4016 2068 7895