Please add basic user management to bzr://

[besy]

I'd like to have basic user management like in svnserve.conf of svnserve. I know that, currently, this isn't possible for bzr:// (https://answers.launchpad.net/bzr/+question/88836), that's why I report this as a wish.

I know there is user management in bzr+ssh:// but it is very difficult to set up a bzr+ssh server (with chrootjail) in Windows (actually, I've never managed to set up the chrootjail...). Without a chrootjail there is always the risk that a bzr+ssh server exposes much more data than only the served repository.

Currently, people who need a smart (fast) server with user authentication but no encryption have to use bzr+ssh://, although they don't need the encryption. A bzr+ssh:// server is much harder to set up than a bzr:// server. Two examples for people who need user authentication but no encryption: a) Project teams who have a Bazaar repository on a server which is only accessible from the company intern LAN and to which only developers may have write access; b) People who have a server which is *only* accessible from VPN connections (because all other ports are deliberately blocked) and who need user authentication for Bazaar

In svnserve.conf it is possible to set which access anonymous users have (none/read/write), which access authenticated users have (none/read/write) and, most important, which users can authenticate themselves (with password).

[Joke de Buhr (joke)]

Any kind of user authentication over unencrypted transports exposes passwords or at least hashes of passwords. Even in company intranets this is a potential security risk. Villains may use wireshark to record foreign branching operations and capture the whole content of a bazaar branch regardless of authentication information or anonymous read access.

If a company trusts it's intranet users they should use a public writeable bazaar smart server over bzr://. They are easily setup.

[besy (besy)]

You are right, authentication for bzr:// wouldn't be safe over unencrypted transports. If someone really wanted to break the authentication, it would work. However, authentication for bzr:// would raise the requirements for unauthorized repository access. Probably enough for many company intern networks. I've seen the use of unencrypted svn:// with simple authentication in several company intern networks.

Apart from that, authentication for bzr:// would be a really nice feature for encrypted transports (e.g. VPN). As far as I know, Bazaar authentication is already possible for http:// which is also unencrypted. If there are reasonable applications for authentication for http://, IMO this means that there are also reasonable applications for authentication for bzr://.

[Martin Pool (mbp)]

I'd like to handle this not by adding our own lame protocol, but by
making it easy to set up a special-purpose ssh server within the bzr
program. This shouldn't allow access to any other resources, and it
wouldn't need to run on port 22. There may already be a bug for this.
 It should be possible to do it using paramiko.