Re: [Cvs-dev] AllowImportOfCVSROOT

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Derek Price <address@hidden> writes:

> Does a AllowImportOfCVSROOT config key that adds the string "CVSROOT"
> to the ignore list and prevents it from being imported in the same way
> "CVS" is restricted make sense to anyone?

Well, restricting the addition of an arbitrary CVSROOT directory into
the repositories sounds like a good idea to me.

> I was thinking that it at least wouldn't do any harm and might prevent
> some people from unwittingly shooting themselves in the foot, but I'm
> always reluctant to restrict the available namespace unless absolutely
> necessary.

I know of a case where someone created a CVSROOT in a repository to hold
the generic scripts used for a number of different repositories. Someone
came along later and used the wrong $CVSROOT specifying a pathname to
the parent of that CVSROOT module and was a ble to do harm to the
sibling part of the $CVSROOT hierarchy in that none of the normal cvs
trigger scripts were used.

> The customer who wants this from me is using commitinfo to restrict
> access to CVSROOT but recently had someone bypass the restriction
> using `cvs import' (though it did no real harm with commits on the
> trunk, it DID alter the archives), so their use case may not be very
> general and I'm thinking the more general fix might be the larger task
> of launching commitinfo & then taginfo on import
> <http://savannah.nongnu.org/patch/index.php?4441>.

Yes, In the best of all possible worlds, I would like to ensure that a
'cvs import' is not accidentally reusing a cvs tag on a new import so
that no existing tags are destructively lost during an import. There is
no way to do this right now.

> Mostly, I guess, I'm just trying to avoid the larger of the two tasks,
> but it's probably necessary.  Any thoughts?

If you are not going through with the full #4441 mechanism, then
adding both an AllowImportOfCVSROOT is another incremental step
to help administrators.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQFGerEyCg7APGsDnFERAhOEAJ9AdXL1ZMA89h+9MGOhUj00/PcJJACeNEJs
VcecG9S5ugTY2bx8kYryHzc=
=6BG4
-----END PGP SIGNATURE-----