On Thu, 20 Jan 2000, Barry A. Warsaw wrote:
We'd have to rework the CVS arrangement in order to give non-CNRI employees write access to the tree. I think I know how I'd go about this, and it wouldn't be too hard, just a bit time-consuming. If that's the way we're going to go, I can start making plans.
Though it may be moot if guido's going to continue mediating the checkins, maybe this would be interesting (if only for barry, to compare procedures). We basically use a captive cvs-":ext:"-over-ssh method, where the captive .ssh/authorized_keys command is quite succinct: command="set $SSH_ORIGINAL_COMMAND; shift; exec cvs $@" 1024 35 ... The shellisms (set/shift/exec cvs $@) lock the user of the qualifying key into executing a cvs command, and only a cvs command. Also, for us the checkins are to a public mirror of our CVS repository, so penetration of the security there doesn't jepordize the master repository base. We don't currently have any outsiders checking into our master repository, and it doesn't seem to me that CVS provides sufficiently managable discretion for doing that. Oh, and a disappointment - the account under which cvs conducts the checkins is the account on the CVS server host, not that of the host where the checkins are being done. This means that you can't use a single account to serve multiple remote users (preventing masquerading quite reliably by using a separate authorized_key public-key entry for each remote user). Therefore we have to have distinct (nailed-down) accounts for each checkin-privileged person - more management burden. Ken