So I wanted to compare the new NCC vs the old one, and found that my CVS was broken.

Don’t you love upgrades that’ll break everything? For some reason now when I cvs init a repo the defaults have changed (where are they even stored?) and it’s been breaking things since going to Debian 9.

Although it presents itself as a warning if you see anything about warnings they apparently are errors. Such as this fine fatal error: “warning: duplicate LogHistory entry found.”. I was getting this from trying to login

cvs [login aborted]: unrecognized auth response from unix.superglobalmegacorp.com: cvs pserver: /ncc/CVSROOT/config [23]: warning: duplicate LogHistory entry found.

But it’s just a warning right? Well it turns out no, and that since I have multiple repos.

Apparently this was a bug in passing going back to 2006!

The problem is that a static variable is defined at line 618 in src/parseinfo.c. It is set when the first --allow-root option is processed for our first repository and then when the second --allow-root option is processed, the warning message is issued (erroneously, I believe) saying that another LogHistory line is encountered. But this is for a completely different repository, so it should have no relevance to the first config file.

Unless, serving multiple repositories is for some reason no longer
supported or the new syntax for using sections in a common config file is now mandatory. I hadn't seen any indications that either were intended, hence my question.

Thanks to Bob Bowen

The way out of this without re-compiling is to now comment out each repo’s LogHistory. Great.

The next issue at least presented itself as an error! .. if that’s progress.

$ cvs -d:pserver:[email protected]:/ncc ls .
cvs ls: failed to create lock directory for `/ncc' (/ncc/#cvs.lock): Permission denied
cvs ls: failed to obtain dir lock in repository `/ncc'
cvs [ls aborted]: read lock failed - giving up

Yep, now the lock directory needs to be specified. Maybe I should have made one per directory although this is pretty much just a read-only anoncvs so I don’t think it matters. And looking back on the logs it was only used by a few people so, honestly that’s fine.

The final error goes back to something I must have figured out with a template that is now wiped out. I have the CVS book, but left it at the office, so I’m here just hacking as a guess, but there is no passwd file being copied into place.

Logging in to :pserver:[email protected]:2401/ncc
CVS password:
Fatal error, aborting.
anonymous: no such user

This is at least simple to take care of, Just copy one from an older repo to a central location and propagate it everywhere. There is no point in doing system authentication as again it’s readonly and I don’t want users on my cvs crap thing.

So in 3 easy lines to remediate the thing, it is:

find ./ -type d -name CVSROOT -exec sed -i 's/LogHistory\=TMAR/#LogHistory\=TMAR/g' {}/config \;
find ./ -type d -name CVSROOT -exec sed -i 's/#LockDir\=\/var\/lock\/cvs/LockDir\=\/var\/lock\/cvs/g' {}/config \;
find ./ -type d -name CVSROOT -exec cp /virtual/unix/SOURCE/cvs-passwd {}/passwd

Current repos include such hits as:

  • 32v
  • binutils
  • cblood
  • cci
  • coherent
  • Corridor8
  • CSRG
  • darwin0
  • darwinstep
  • djgppv1
  • dmsdos
  • doom
  • dynamips
  • frontvm
  • gas
  • gcc130-x68000
  • gcc1x
  • gcc2x
  • gdb
  • gnumach
  • gsmaster
  • hatari
  • linux
  • linux001
  • lites
  • mach
  • mach3
  • machki386
  • MacMiNT
  • MiNT
  • msdos-player
  • ncc
  • net2
  • nextstep33examples
  • ntsdk
  • os2sdk
  • pgp
  • plan9next
  • previous
  • qemu
  • quake1
  • quake2
  • research
  • rsaref
  • sbbs
  • simh
  • TekWar
  • tme
  • truecrypt
  • uae
  • Witchaven
  • WitchavenII
  • xinu
  • xnu

General instructions are still valid on My crappy CVS archive of old crap is now online via pserver!

$ cvs --version

Concurrent Versions System (CVS) 1.12.13-MirDebian-25 (client/server)
$ cvs -d:pserver:[email protected]:/research login
Logging in to :pserver:[email protected]:2401/research
CVS password:
$ cvs -d:pserver:[email protected]:/research ls .
CVSROOT
researchv10dc
researchv10no
researchv3
researchv6
researchv6id
researchv6kw
researchv7hs
researchv7kb
researchv7ni
researchv7th
researchv8dc
researchv9

7 thoughts on “So I wanted to compare the new NCC vs the old one, and found that my CVS was broken.

  1. I dropped a line to mira(who maintain cvs-MirDebian) in IRC(#!/bin/[email protected]) and he told me:
    heh, LogHistory works for me, but then, pserver is no longer supported 😀
    serving multiple repos is an interesting case
    anoncvs servers are supposed to use -R or set CVSREADONLYFS
    they then need no lock directory
    I can have a look at the LogHistory thing, but I’d have to figure out how to “serve multiple repositories via pserver” first…
    the NEWS.Debian for 2:1.12.13+real-5 documents that “pserver is no longer officially supported”
    2:1.12.13+real-22 documents the LogHistory security fix
    and I know I documented CVSREADONLYFS in the texinfo documentation
    if you know the author, can you please forward this, and that I’m available for discussion
    (and strongly suggest anoncvs over ssh, also documented in NEWS.Debian)
    pserver does not use ssh and is therefore very MITM vulnerable
    we’ve been using anoncvs over ssh for decades now
    I originally planned to remove it entirely

      • Yes wordpress is quite annoying with the .GT & .LT ..

        As much as I like worrying about MITM for source code from 1986, the problem is that when I connect to the internet on my machine using an OS from 1990 is that I can’t access anything anymore.

        Which I fully expect people to generally not care anymore but here we are lol.

        I guess I’ll have to build my own from source eventually if they are going to pull pserver. At least that is still an option.

        • mira saw your comment and leave you a message:
          <mira|AO> mh
          <mira|AO> tell him I’ll have a look at it and will try to fix the message, and he should just add “env CVSREADONLYFS=1” in front of the cvs pserver line in inetd.conf(?)
          <mira|AO> and that I’m just as annoyed by people disallowing TLSv1.0 even if they don’t need bank-level security and can’t access sites with my old BSD any more

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.