-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Derek Price <[EMAIL PROTECTED]> writes:
> Mark D. Baushke wrote:
>
> > Derek Price <[EMAIL PROTECTED]> 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-----
_______________________________________________
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
