Guy Rouillier [off-list ref] writes:
To answer Junio's question, I'm looking at the CVSNT code now
(GlobalSettings.cpp, if anyone is interested.) The password is stored
in a general fashion like any other user-specified value. So, the
authors elected to use a properties file format of key=value. That is
as valid a format as any other.
As you dug that far, could you find out what happens when cvsroot contains
an equal-sign character in its path component?
I am starting to suspect that we do need two separate codepaths, and we
would need to split out the logic to find matching password entry given a
cvsroot value into a separate function to keep our sanity after all.
On 2/22/2011 7:45 PM, Junio C Hamano wrote:
Guy Rouillier[off-list ref] writes:
quoted
To answer Junio's question, I'm looking at the CVSNT code now
(GlobalSettings.cpp, if anyone is interested.) The password is stored
in a general fashion like any other user-specified value. So, the
authors elected to use a properties file format of key=value. That is
as valid a format as any other.
As you dug that far, could you find out what happens when cvsroot contains
an equal-sign character in its path component?
I am starting to suspect that we do need two separate codepaths, and we
would need to split out the logic to find matching password entry given a
cvsroot value into a separate function to keep our sanity after all.
I'll take a look. I spent a short amount of time with Google looking
for "cvsroot valid characters" but didn't find anything authoritative.
Note that this issue is not unique to CVSNT. What does CVS do with
CVSROOT containing a space character?
--
Guy Rouillier
On 2/23/2011 12:24 AM, Junio C Hamano wrote:
Guy Rouillier[off-list ref] writes:
quoted
... Note that this issue is not unique to CVSNT. What does CVS do
with CVSROOT containing a space character?
IIRC, the comparison is done against canonicalized cvsroot string, so
that you can try to connect to :pserver:Xz.Com:/path/to/repo even
after you ran "cvs -d :pserver:xz.com:/path/to/repo login" and I
wouldn't be surprised if the canonicalization involved quoting SP.
Since August 2009 nobody has complained with the current code that
doesn't do any canonicalization, and I take that as a sign that
nobody sane so far used a cvsroot with a space in it ;-). But that
doesn't mean nobody sane has been using a cvsroot with an equal sign
in it, so we would need to at least avoid splitting at an equal sign
when reading from .cvsroot.
It probably is a good idea to port the cvsroot canonicalization code
to cvsimport in any case.
As I suspected after reading how the cvspass file is read and written,
CVSNT doesn't work with repositories with an equal sign in the
repository name. You can init it fine, and you can set up a password
for it. But if you try to login things go very wrong:
guyr@gentoo-vm /data $ cvs -d
":pserver:guyr@gentoo-vm:2401:/data/cvs\=repo/cvsroot" login
Logging in to :pserver:guyr@gentoo-vm:2401:/data/cvs\=repo/cvsroot
CVS Password:
Empty password used - try 'cvs login' with a real password
cvs [login aborted]: /data/cvs\=repo/cvsroot: no such repository
I tried as many permutations as I could think of, escaping the equal
sign, not escaping it, etc. None of them worked. I did verify my
environment before running this test by setting up a repository without
the equal sign in the name, and everything works fine.
Since CVSNT can't handle a repository with an equal sign in its name, I
say we don't worry about this. I say the same about the original CVS
with a repository name with embedded spaces. We certainly don't want to
try to solve problems the original product doesn't solve.
--
Guy Rouillier