>> 1) Reopen SR #107077 (it's currently marked "closed", yet has much >> recent discussion and planning).
Done now. >> 2) With bzr developer Robert Collins, write up a plan for exactly how >> to provide Bazaar bzr+ssh:// access securely on Savannah. This >> will involve taking various steps mentioned in SR #107077. Start >> at https://savannah.gnu.org/support/?107077#comment20 and read >> upwards if you're curious. Okay, below is an implementation plan. Robert Collins has helped with advice on this; I'm CC'ing him here in case I mess anything up. I'm assuming we already have an id_rsa.pub or id_dsa.pub from every potential committer, or that we can easily get committers' public keys by having them submit it through the Savannah web interface. On bzr.sv.gnu.org: 1. Create a new group 'bzrusers'. 2. Do 'chgrp -R bzrusers /srv/bzr && chmod -R g+w /srv/bzr' (/srv/bzr is the top of our Bazaar "shared repository", right?) 3. For each committer Jennifer Random, create a Unix account 'jrandom' and put her in the group 'bzrusers'. Her shell should be /bin/sh (not /bin/false), but the account should have no login password -- i.e., use "*" in the encrypted password field in /etc/shadow or whatever. All authentication will be done via SSH, and we will allow only a restricted command set there (see below). 4. In ~jrandom/.ssh/authorized_keys, put this line: command="/usr/bin/bzr serve --inet --allow-writes --directory=/src/bzr" ssh-rsa <<<LONG BASE64 PUBLIC KEY>>> jran...@clientcomment NOTE: everything from "ssh-rsa ..." on is either from id_rsa.pub as supplied by jrandom, or is a dedicated-use public key supplied by jrandom. In the latter case, jrandom would have something like this in .ssh/config on the client side: Host bzr.sv.gnu.org IdentityFile ~/.ssh/savannah_id_rsa 5. (paranoia) Do 'chmod 600 ~jrandom/.ssh ~jrandom/.ssh/authorized_keys' 6. (paranoia) Make sure that /usr/lib/python2.*/bzrlib/plugins/ is not writeable by jrandom -- though it shouldn't matter, since SSH access is restricted to bzr only and bzr is restricted to the /bzr/srv directory (via the "--directory" option). 7. (paranoia) Make sure ~jrandom/.bazaar/plugins does not exist or is not writeable by jrandom. NOTE: We may someday put real plugins in there, or make it a symlink to a shared plugin directory controlled by the sysadmins. But in any case jrandom should not be able to configure it. On the client side: Commands like these should now work, assuming /bzr/srv/projectname exists and has a 'trunk' branch (e.g., projectname is "emacs"): $ bzr branch bzr+ssh://[email protected]/projectname/trunk $ cd trunk $ echo "Hello, world!" > foo $ bzr add foo $ bzr commit -m "Add file 'foo'." $ bzr push --remember bzr+ssh://[email protected]/projectname/trunk Pushed up to revision <<<N>>>. $ NOTES: If the remote branches were not created with the --no-trees option, or 'bzr remove-tree' has not been run on them, then the client will get a warning like this: This transport does not update the working tree of: bzr+ssh://[email protected]/projectname/trunk/. See 'bzr help working-trees' for more information. I assume we configure all our branches on the server to not have working trees, so this won't be an issue. Also, note that even if jrandom has Unix password-based access on the remote server, it will not work with this Bazaar configuration... [email protected]'s password: ********* bzr: ERROR: Not a branch: "bzr+ssh://[email protected]/testproj/". ...because the key Bazaar line is in ~jrandom/.ssh/authorized_keys, so authentication must happen via SSH private/public key. That's the plan. It may need to be tweaked, depending on the situation on bzr.sv.gnu.org, but I think the rough outline is about right. Comments welcome. Both Robert and I will be at the GNU hacker meetup in Boston; we're happy to help make this happen then, if not sooner. -Karl
