bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: history and val-tags locks.


From: Mark D. Baushke
Subject: Re: history and val-tags locks.
Date: Wed, 27 Apr 2005 14:35:03 -0700

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

Derek Price <derek@ximbiot.com> writes:

> Mark D. Baushke wrote:
> 
> > Derek Price <derek@ximbiot.com> writes:
> 
> I won't.  My apologies for cutting and pasting the list above out of
> context from an email I received.

Good, sorry for sounding alarmist. :-)

> > Am I correct in assuming that this change also assumes handling
> > expansions of internal CVS variables like $CVSROOT is being added to to
> > CVSROOT/config processing and that those are NOT general purpose
> > environment variables being added?
> 
> Yes.  I'll probably hook into the same function used to do this by the
> trigger scripts, expand_path().  This should enable the same config file
> to be used in multiple CVS roots as well.

This sounds reasonable to me.

> An associated change I was putting off talking about was adding a
> global `-c <config_file>' option to cause CVS to look elsewhere for
> its configuration file.

I worry about the security implications of this one. I don't believe it
can be allowed for anythiner other than :pserver: mode where the
administrator takes care of arguments to the cvs executable directly.

If the user may provide a config file that specifies the commitinfo
triggers to use, it could subvert the intention of the repository
administrator. The administrator could get the same effect by putting a
symbolic link into CVSROOT for the config file... of course, it would be
well to ensure that rebuilding the repository database would not destroy
that link.

> That is what I meant.  I had thought that a "file glob" was not precise
> and referred to a whole class of path expansion, using patterns like
> "name.??.* ", and implemented by various functions including fnmatch.  I
> use the term in the same way I might specify "regex" matching when I
> don't see a need to be more precise (e.g. "basic regex", "extended
> regex", "perl regex", etc.).  I completely intended and continue to
> intend to use the POSIX fnmatch() we've already imported from GNULIB to
> implement this matching and any similar matching in the future.

Good. (I was just trying to be very clear and not misrepresent your
intention.)

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

iD8DBQFCcAWH3x41pRYZE/gRAtlWAKC2HoNtPj7aY8w/BHIisfEqU6lE3QCg2OU2
OwbgnsvZJaAt+rudYSHcxPc=
=lVJk
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]