Smart server has no built in authentication

Bug #126911 reported by Robert Collins on 2007-07-19
52
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Unassigned
Breezy
Wishlist
Unassigned

Bug Description

This has turned up in a few places, it would be good to be able to
manage authentication, and presumably access control within the smart
server.

This is kindof optional on http://, but really required on bzr://.

It would be nice to be able to do quick-hacks for sprints with something
like bzr server --username=foo --password=bar, to provide an on-demand
central server with no config.

 affects /products/bzr
 status triaged
 importance high
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Vincent Ladeuil (vila) wrote :

<lifeless> womble: setup a service account
<lifeless> womble: bzr+ssh://foo@host/.../
<lifeless> womble: with restricted access to only run as that user. If this helps.

Looks like the perfect solution to me :)

bzr://

no authentication

bzr+http://

optional authentication

bzr+ssh://

Strong authentication either for each user or with a dedicated account registering the authorized keys.

We were to *not* manage authentication ourselves. I'll strongly prefer we continue :)

Lowering the importance as I think it's more a documentation problem. Feel free to disagree or bring the discussion to the list.

Changed in bzr:
importance: High → Low
Robert Collins (lifeless) wrote :

That clearly fails the use case I gave because it requires much more than 'bzr serve --username --password'.

bzr:// is a registered internet protocol, we should make sure its solid enough to use as one.

Vincent Ladeuil (vila) wrote :

For the sprint use case, it's also possible to create a temporary shh account, give its password to sprint participants and use bzr+ssh://

Vincent Ladeuil (vila) wrote :

<lifeless> vila: I think you are massively oversimplifying the headache of setting up ssh or http.
<lifeless> vila: by about 10000:1 in terms of time vs what I am proposing we be able to offer.
<vila> apt-get sshd
<vila> adduser sprint
<lifeless> also in terms of requiring root access or other such things
<lifeless> you just failed twice.
<lifeless> three times in fact
<lifeless> a) requires you have internet. b) both commands need root access.
<jamesh> lifeless: you could always use cvs-pserver style authentication
<lifeless> jamesh: right; we've even got the code for that :)
<jamesh> it has good error codes
<vila> oooh, wow, who don't have internet + root access on its local machine in sprints ?
<vila> anyway, put the importance back to high if you prefer
<lifeless> vila: no internet is actually fairly common. Last sunday that happened to me.
<spiv> Sprints/conferences regularly have poor internet access :(
<vila> I thought we were talking about LAN access inside the sprint
<jamesh> vila: setting up a properly locked down ssh account requires a few extra steps
<lifeless> vila: as for no root - not everyone owns their own laptop, having root is not guaranteed, to be really usable this stuff needs to be doable on the fly as the main user.
<jamesh> vila: I might trust the other people to pull from the branches I am publishing, but don't really want to provide access to everything else on the system
<vila> ok, ok, I'll go hide under a rock :)
<lifeless> vila: think 'right click on bzr's gui. Select share branches. click add branch. select the path, and click on 'authenticated''
* bubba (<email address hidden>) has joined #bzr
<lifeless> vila: so the question for me is 'is the complexity worth it', not 'can people survive without it'
<vila> user is always right, forget my hacker style solution :)

Vincent Ladeuil (vila) wrote :

I misunderstood the needs.

Changed in bzr:
importance: Low → High
Vincent Ladeuil (vila) wrote :

brain dump:

what kind of protection do we want to offer with a bzr specific authentication ?

Should we go with user/password transmitted in the clear or do we want to encrypt that part of the protocol ?

Do we want to encrypt all the protocol as soon as authentication is used ?

Do we want to encrypt all the protocol wether or not the the authentication is used ?

What encryption do we want to use ?

Should we bring that discussion to the list ? Now or when we specify the bzr authentication ?

Martin Pool (mbp) wrote :

I think it would be interesting to have it use paramiko to run an ssh server (on a nondefault port). Whether that is a good idea or not can be discussed on the list.

I kind of think we should make hpss faster before doing optional features like this.

It would be good to have this discussion on the list, and come to the
bug when some consensus forms.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Martin Pool (mbp) on 2008-01-15
Changed in bzr:
importance: High → Medium
Michael B. Trausch (mtrausch) wrote :

Because I am not on the list or anything like that, I will place my own comments on this issue here—I think that it would be very much desirable to have some sort of basic authentication built-in to the bzr protocol, much like what svnserve does for repositories serviced under it. Perhaps a simple config file under the repo/branch directory that specifies a username and password for access, and then access by "group" or category... for example, users who are anonymous can do nothing, users who authenticate in the "drones" category can commit, and users who authenticate as non-programmers can read. Or anon = read, authenticated user=write, or whatever.

It wouldn't need to be terribly complex for many use cases... it's rather ad-hoc anyway. If the user requires encryption and thus protection of their repository when transmitted over the wire, they should be using https:// or bzr+ssh://, but there are some users who (admittedly thinking in the model of centralized development) would want to have a simple bzr:// that just works with usernames and passwords setup for it.

Just my 2¢...

Jelmer Vernooij (jelmer) wrote :

It would be nice to support SASL-compatible authentication challenge/response authentication.

Vincent (vincent-) wrote :

In our university lab we are setting up a hub for project developments. Trac tracks the bugs and manage the users. Bazaar and SVN would be the VCS tools (depending on the project).

The SSH does not fit our requirements since there's no matching between the SSH users and the Trac users (htpasswd file) -> not convenient at all for the management and the users.

For SVN, the solution is to use Apache+WebDAV. There is a module, "dav_svn", that permits to use apache as a smart server for svn! In addition, it allows to use fine grained permissions on a per file or per directory basis through a "authz " file.
Users are sourced from the Trac's htpasswd file.

For Bazaar over WebDAV, users can also be matched with the Trac's htpasswd file, thanks to Apache stuff. Unfortunately, WebDAV remains dumb against Bazaar :-(

In conclusion:

A great feature that could make WebDAV smarter ;-) for Bazaar: a "dav_bzr" module for Apache with the same scope as the "dav_svn" module (with authz feature and autoversioning).

John A Meinel (jameinel) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vincent Boucher wrote:
> In our university lab we are setting up a hub for project developments.
> Trac tracks the bugs and manage the users. Bazaar and SVN would be the
> VCS tools (depending on the project).
>
> The SSH does not fit our requirements since there's no matching between
> the SSH users and the Trac users (htpasswd file) -> not convenient at
> all for the management and the users.
>
> For SVN, the solution is to use Apache+WebDAV. There is a module, "dav_svn", that permits to use apache as a smart server for svn! In addition, it allows to use fine grained permissions on a per file or per directory basis through a "authz " file.
> Users are sourced from the Trac's htpasswd file.
>
> For Bazaar over WebDAV, users can also be matched with the Trac's
> htpasswd file, thanks to Apache stuff. Unfortunately, WebDAV remains
> dumb against Bazaar :-(
>
> In conclusion:
>
> A great feature that could make WebDAV smarter ;-) for Bazaar: a
> "dav_bzr" module for Apache with the same scope as the "dav_svn" module
> (with authz feature and autoversioning).
>

You can already proxy the bzr smart server over http requests. See
http://doc.bazaar.canonical.com/latest/en/user-guide/http_smart_server.html

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktzG0YACgkQJdeBCYSNAAN5dwCggTCeKDYNAB3/emPNt5Dgj25z
/hsAn02qgAwrHuzTMUqGPxpiysgfuXvw
=Rip9
-----END PGP SIGNATURE-----

Martin Pool (mbp) on 2010-03-18
Changed in bzr:
status: Triaged → Confirmed
Jelmer Vernooij (jelmer) on 2011-02-01
tags: added: authentication hpss
Jelmer Vernooij (jelmer) on 2017-11-08
tags: added: check-for-breezy
Jelmer Vernooij (jelmer) on 2018-05-12
Changed in brz:
status: New → Triaged
importance: Undecided → Wishlist
tags: removed: check-for-breezy
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers