
- •Overview
- •What is CVS?
- •What is CVS not?
- •A sample session
- •Getting the source
- •Committing your changes
- •Cleaning up
- •The Repository
- •Telling CVS where your repository is
- •How data is stored in the repository
- •File permissions
- •The attic
- •The CVS directory in the repository
- •CVS locks in the repository
- •How data is stored in the working directory
- •Multiple repositories
- •Creating a repository
- •Backing up a repository
- •Moving a repository
- •Remote repositories
- •Server requirements
- •Connecting with rsh
- •Direct connection with password authentication
- •Setting up the server for password authentication
- •Using the client with password authentication
- •Security considerations with password authentication
- •Direct connection with GSSAPI
- •Direct connection with Kerberos
- •Connecting with fork
- •Distributing load across several CVS servers
- •Read-only repository access
- •Temporary directories for the server
- •Starting a project with CVS
- •Creating Files From Other Version Control Systems
- •Creating a directory tree from scratch
- •Revisions
- •Revision numbers
- •Versions, revisions and releases
- •Assigning revisions
- •Specifying what to tag from the working directory
- •Specifying what to tag by date or revision
- •Deleting, moving, and renaming tags
- •Sticky tags
- •Branching and merging
- •What branches are good for
- •Creating a branch
- •Accessing branches
- •Branches and revisions
- •Magic branch numbers
- •Merging an entire branch
- •Merging from a branch several times
- •Merging and keywords
- •Recursive behavior
- •Removing directories
- •The Normal way to Rename
- •Moving and renaming directories
- •History browsing
- •Log messages
- •The history database
- •Multiple developers
- •File status
- •Informing others about commits
- •Several developers simultaneously attempting to run CVS
- •Telling CVS to notify you
- •Information about who is watching and editing
- •Using watches with old versions of CVS
- •Choosing between reserved or unreserved checkouts
- •Revision management
- •When to commit?
- •Keyword substitution
- •Keyword List
- •Using keywords
- •Avoiding substitution
- •Substitution modes
- •Problems with the $Log$ keyword.
- •Tracking third-party sources
- •Updating with the import command
- •Reverting to the latest vendor release
- •How to handle keyword substitution with cvs import
- •Multiple vendor branches
- •How your build system interacts with CVS
- •Special Files
- •Calendar date items
- •Index
Chapter 2: The Repository |
27 |
(or in some cases processes that act as an administrative user) are typically given access to modify this file. Either there needs to be some hand-crafted web page or set-uid program to update the file, or the update needs to be done by submitting a request to an administrator to perform the duty by hand. In the first case, having to remember to update a separate password on a periodic basis can be di cult. In the second case, the manual nature of the change will typically mean that the password will not be changed unless it is absolutely necessary.
Note that PAM administrators should probably avoid configuring one-time-passwords (OTP) for cvs authentication/authorization. If OTPs are desired, the administrator may wish to encourage the use of one of the other Client/Server access methods. See the section on see Section 2.9 [Remote repositories], page 19 for a list of other methods.
Right now, the only way to put a password in the cvs ‘passwd’ file is to paste it there from somewhere else. Someday, there may be a cvs passwd command.
Unlike many of the files in ‘$CVSROOT/CVSROOT’, it is normal to edit the ‘passwd’ file in-place, rather than via cvs. This is because of the possible security risks of having the ‘passwd’ file checked out to people’s working copies. If you do want to include the ‘passwd’ file in checkouts of ‘$CVSROOT/CVSROOT’, see Section C.6 [checkoutlist], page 168.
2.9.4.2 Using the client with password authentication
To run a cvs command on a remote repository via the password-authenticating server, one specifies the pserver protocol, optional username, repository host, an optional port number, and path to the repository. For example:
cvs -d :pserver:faun.example.org:/usr/local/cvsroot checkout someproj
or
CVSROOT=:pserver:bach@faun.example.org:2401/usr/local/cvsroot cvs checkout someproj
However, unless you’re connecting to a public-access repository (i.e., one where that username doesn’t require a password), you’ll need to supply a password or log in first. Logging in verifies your password with the repository and stores it in a file. It’s done with the login command, which will prompt you interactively for the password if you didn’t supply one as part of $CVSROOT:
cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot login CVS password:
or
cvs -d :pserver:bach:p4ss30rd@faun.example.org:/usr/local/cvsroot login
After you enter the password, cvs verifies it with the server. If the verification succeeds, then that combination of username, host, repository, and password is permanently recorded, so future transactions with that repository won’t require you to run cvs login. (If verification fails, cvs will exit complaining that the password was incorrect, and nothing will be recorded.)
The records are stored, by default, in the file ‘$HOME/.cvspass’. That file’s format is human-readable, and to a degree human-editable, but note that the passwords are not stored in cleartext—they are trivially encoded to protect them from "innocent" compromise (i.e., inadvertent viewing by a system administrator or other non-malicious person).