From the NEWS file of cvs 1.11.11:
* pserver can no longer be configured to run as root via the
$CVSROOT/CVSROOT/passwd file, so if your passwd file is
compromised, it no longer leads directly to a root hack. Attempts
to root will also be logged via the syslog.
* Malformed module requests could cause the CVS server to attempt
to create directories and possibly files at the root of the
filesystem holding the CVS repository. Filesystem permissions
usually prevent the creation of these misplaced directories, but
nevertheless, the CVS server now rejects the malformed requests.
Obtained from: ccvs.cvshome.org
of the bugs that I know of. We've been running a slightly older version
of this on freefall/repoman, where it was afflicted by a silly merge error
on my part (fixed).
Approved by: re
---
Fix communication hanging in communication shutdown phase, caused by at
least older CVS clients (version < 1.11.2) and a semantically incorrect
usage of getc() by the server.
---
getc() was being used on a blocking socket/pipe.
Submitted by: rse
for the trouble that DES and I had with MFCs: when "cvs update -jfoo -jbar"
creates a new file, it sets the version to 0 ("new") but sets the timestamp
in the Entries file to the timestamp of the file that's new on the branch.
The CVS client doesn't upload files whose timestamps match with the Entries
file, so these new files don't get uploaded to the server and the server
fails when trying to check them in.
PR: bin/40227
Approved by: peter
MFC after: 2 weeks
support that already exists for checkout. The -T option for cvs update
and cvs checkout may be used to cause CVS to retrieve/update the checkin
template when possible.
MFC after: 1 week
"-D date" command line option. There is code in the original to
handle a special case. If the date search finds revision 1.1 it
is supposed to check whether revision 1.1.1.1 has the same date
stamp, which would indicate that the file was originally brought
in with "cvs import". In that case it is supposed to return the
vendor branch version 1.1.1.1.
However, there is a bug in the code. It actually compares the date
of revision 1.1 for equality with the date given on the command
line -- clearly wrong. This commit fixes the coding bug.
There is an additional bug which is _not_ fixed in this commit.
The date comparison should not be a strict equality test. It should
allow a fudge factor of, say, 2-3 seconds. Old versions of CVS
created the two revisions with two separate invocations of the RCS
"ci" command. We have many old files in the tree in which the
dates of revisions 1.1 and 1.1.1.1 differ by 1 second.
Approved by: peter
checkouts from a local repo and committing via remote cvs. A cvs -d
override of the mismatched CVS/Root files was missing. This is a client
side fix, I'd appreciate it if the folks having trouble with this would
update their cvs client and pay particular attention next time..
