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

[John Arbash Meinel]

Daniel Silverstone wrote:
> On Mon, 2008-01-21 at 20:58 +1100, Andrew Bennetts wrote:
>>> Perhaps we should just do this bump now, there's a couple of things accumulating
>>> that we could fix in a new protocol version:
>>>
>>>   * reliably consume bodies of unrecognised requests (and responses)
>>>   * an explicit, clean way for a server to signal to the client that a request
>>>     verb is unrecognised
>>>   * sending client version information
>> Oh, and something else that would be nice:
>>
>>   * allowing 8-bit clean request/response args (i.e. provide a way to encode
>>     0x01 and 0x0a).
> 
> If you're doing a new protocol version then some nod towards
> authentication would be nice, particularly if you could integrate
> something along the lines of the bzr_access script's config from the
> contrib/ directory. Unfortunately because bzr+ssh always passes
> --directory=/ the bzr_access script is currently utterly useless as far
> as I can tell.
> 
> D.
> 

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.

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)

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.


John
=:->