Re: login failure on WindowsNT
[EMAIL PROTECTED] wrote: The method should be in the URI prefix since it really does identify the communication protocol. Save "cvs" for the standard CVS protocol; cvs-p perhaps for pserver, cvs-ssh for SSH, etc. The method name does not belong in the URI body. My thought here was that without an overriding need for a URI immediately, it might be worth spending the time consolidating the protocols first. They're not very different in the first place. Then cvs:// could mean connect to port 2401 and ask what authentication methods are valid. The server would respond with a list and the client would use whatever it thinks is the most secure to authenticate and set up an encryption stream. I'm thinking :ext: would still need its own URI prefix. And probably :local:. pserver, gserver, and kserver are almost identical except for the auth methods, though. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- There are plenty of businesses like show business. There are plenty of businesses like show business. There are plenty of businesses like show business... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: login failure on WindowsNT
Then cvs:// could mean connect to port 2401 and ask what authentication methods are valid. The server would respond with a list and the client would use whatever it thinks is the most secure to authenticate and set up an encryption stream. Oooh, no, you *DON'T* want to do that -- it's a classic "man in the middle" attack. I can sit between you and the server and force you to downgrade to a lower security level. Early SSL had this problem. Designing security protocols is hard. Recommend we stick to one hard problem (source control) here. /r$ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: login failure on WindowsNT
Pradeep Picardo wrote: The version of cvs we are using on unix here has been hacked. I found out about that only last night. I have rebuilt cvs on windows to pick up the port number from the environment the way our unix version does. Should I pass on the code so it can be incorporated into the main distribution ? (Because it does seem like a needless omission to me.) You're welcome to send it on, of course. I'm about to check in code to allow both CVS_CLIENT_PORT to be specified in the environment and to allow the port to be specified as part of CVSROOT, but someone may want the information in the meantime or your patch may include something I missed. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Conscious is what you are aware of and conscience is what you wish you weren't. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: login failure on WindowsNT
The necessary code is already there in the function start_tcp_server(), it
just needs to be 'cut and pasted' into connect_to_pserver().
I'm attaching the output of the diff command to this mail, I believe
there's something called 'patch' but I'm a windows guy and am not familiar
with the unix conventions regarding submitting code patches. (Any guidance is
welcome :-) ).
In case you need a name to attribute this code change to - its Ravindra
Naik.
- Pradeep.
note: client.c is the modified file, client.c.orig is the file as
distributed (cvs-1.11.tar.gz).
$diff client.c client.c.orig
3777,3779d3776
/* RDN 26052000 */
const char *portenv;
/* RDN 26052000 */
3794,3816c3791,3792
/* RDN - 26052000 */
/* Get CVS_CLIENT_PORT or look up cvs/tcp with CVS_PORT as default
*/
portenv = getenv ("CVS_CLIENT_PORT");
if (portenv != NULL)
{
port_number = atoi (portenv);
if (port_number = 0)
{
error (0, 0, "CVS_CLIENT_PORT must be a
positive number! If you");
error (0, 0, "are trying to force a
connection via rsh, please");
error (0, 0, "put \":server:\" at the
beginning of your CVSROOT");
error (1, 0, "variable.");
}
if (trace)
fprintf(stderr, "Using TCP port %d to
contact server.\n", port_number);
}else {
port_number = auth_server_port_number ();
}
/*port_number = auth_server_port_number ();*/
/* RDN - 26052000 */
hostinfo = init_sockaddr (client_sai, CVSroot_hostname,
port_number);
---
port_number = auth_server_port_number ();
hostinfo = init_sockaddr (client_sai, CVSroot_hostname,
port_number);
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: login failure on WindowsNT
I thought CVS looked up the port number in the services file using a getservbyname call. I have CVS on NT AIX talking to CVS server running on a separate AIX node that is listening on port 11001. This was done by setting the cvspserver in the services file on all the machines (NT/client, AIX/client and AIX/server). Regards John Scott. -Original Message- From: Derek R. Price [mailto:[EMAIL PROTECTED]] Sent: 12 October 2000 14:57 To: Pradeep Picardo Cc: [EMAIL PROTECTED] Subject: Re: login failure on WindowsNT Pradeep Picardo wrote: The version of cvs we are using on unix here has been hacked. I found out about that only last night. I have rebuilt cvs on windows to pick up the port number from the environment the way our unix version does. Should I pass on the code so it can be incorporated into the main distribution ? (Because it does seem like a needless omission to me.) You're welcome to send it on, of course. I'm about to check in code to allow both CVS_CLIENT_PORT to be specified in the environment and to allow the port to be specified as part of CVSROOT, but someone may want the information in the meantime or your patch may include something I missed. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Conscious is what you are aware of and conscience is what you wish you weren't. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs The information contained in this message or any of its attachments may be privileged and confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using the reply facility in your e-mail software. All messages sent and received by Argos Ltd. are checked for malicious content. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: login failure on WindowsNT
Pradeep Picardo wrote: The necessary code is already there in the function start_tcp_server(), it just needs to be 'cut and pasted' into connect_to_pserver(). Okay, this is basically what I did, but thanks anyhow. Also, when passing diffs, in general a 'diff -c' is required for patch. 'diff -u' is even better, but I understand that not all versions of patch support that format yet. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- HAMLET No, not I. I never gave you aught. OPHELIA My honoured lord, you know right well you did, And with them words of so sweet breath composed As made the things more rich. Their perfume lost, Take these again. For to the noble mind Rich gifts wax poor when givers prove unkind. There, my lord. - Hamlet, Act III, Scene 1, Lines 96-102 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: login failure on WindowsNT
Larry Jones wrote: Have you looked at the various proposed patches and related commentary at http://www.cvshome.org/cyclic/cvs/dev-net.html under "Change pserver port"? To add my $.02 to what Jim K. has written there, using an environment variable to specify the port is bletcherous -- the port I think you're right here, but the variable was already being supported for GSSAPI. It looked rather harmless to expand the functionality to include pserver should help prevent a few FAQs. number is a characteristic of the server and thus belongs in CVSROOT. As discussed on the above-mentioned page, however, there's no concensus as to an exact syntax. The idea of using something URLish is quite attractive -- perhaps something along the lines of: pserver://user@host:port/cvsroot My only problem here is declaring the method. I suppose we could overload cvs-*, using cvs-pserver, cvs-kserver, cvs-gserver, cvs-rsh, (extend to cvs-ssh? this brings up issues) and perhaps this is the best short-term solution, but looking ahead I want to say that all valid URLs should start with "cvs://" and deciding what connection method and what authentication method to use should be part of the following URL. cvs://method/user@host:port/cvsroot? Then a browser could know that all cvs:// URLs go to a CVS client and not worry further about syntax. Ideally, whether to use pserver authentication, Kerberos, GSSAPI, or some other authentication method should be defined as part of the standard CVS protocol and not be part of the URL at all as the majority of the protocol is the same and the various bits only specify authentication methods. Back to: cvs://user@host:port/cvsroot regardless of connection and authentication methods. Unfortunately, I'm unsure that RSH and SSH can be easily specified as connection methods in this manner. The only tricky part is distinguishing the new syntax from the old syntax to maintain upward compatibility. The docs you pointed me at mention scanning for '//'. It isn't exactly illegal in the old syntax, but it might suffice. "^method://" should actually be pretty tight. If we want to continue with the existing syntax, then I'd suggest: :pserver:user@host:port/cvsroot rather than any of the other schemes that have been proposed. I do want this functionality immediately, so I will change my host/port syntax to this syntax. I like it better. I have more to say, I think, but I have to run for an hour, so I'm sending this off to see if it can gather any more comments regarding the URL syntax. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I don't suffer from stress. I'm a carrier. - Scott Adam's _Dilbert_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: login failure on WindowsNT
Larry Jones wrote: cvs://method/user@host:port/cvsroot has a / in the "server" part, which isn't allowed; I'd suggest : instead: Didn't remember that. Ok. cvs://method:user@host:port/cvsroot I was hoping to make both 'user' 'method' optional, so, with an optional port, and leaving room for named ports, a parser won't easily be able to distinguish method:host from host:port Another possibility would be: cvs://:method:user@host:port/cvsroot which looks a little funny, but has the nice property that what comes after the // is exactly a CVSROOT specification. I was thinking this might be the way to go, and it does resolve both the above problems. I hadn't thought it through enough yet to realize that it's parsable and really looks like a pretty standard URL. I think it'd have to be: cvs://[:method:][user[:password]@]host[:port]/cvsroot with '[...]' specifying optional parameters, of course. Hmm. Is there a point to this? The basic use case I can come up with would be an anonymous user running a checkout by clicking on a link. Unfortunately, this URL spec doesn't include a module specification. This weakness extends to branches dates. The logic here is that any checkout you could specify on the command line should be specifiable in a URL. Another weakness seems to be an inability to differentiate between :ext: methods. This could maybe be solved by adding an :ssh: method or, alternately, allowing a method syntax like, :rsh-like-program-name@method:. A bit confusing and inextensible, but it should work. Ok. Back to use cases: Without the ability to specify modules, this URL makes sense for a GUI client such as gCVS and a server with the 'ls' patch to allow browsing. (i.e. The user would click the link in a browser, the browser would pass the URL to gCVS, gCVS would login and allow the user to start browsing available modules. Without the ability to specify modules, this URL could also trigger only a login action when clicked. Then the user would be logged in and it could be left to them to figure out what else to do. Easy for us, but the user is still going to have to retype the URL at some point to initiate their first checkout. They'd also have to type a module name. With extra syntax which provides the ability to specify modules, branches, dates, a user could checkout modules, development branches, and releases from anonymous cvs repositories with a single click. With extra syntax to specify which rsh-like program to use, I could provide a link to an anonymous but secure server for a corporate client. Of course, something that can simply be pasted into CVSROOT seems clean at first glance, but why define a URL if you can't click on it for effect from a browser anyhow? And there seems to be a lot of power in a link that allows a new user to download the tip of a project's dev or stable branch in a single click. Comments? Ideas? Problems? More use cases? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Southern DOS: Y'all reckon? (yep/Nope) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: login failure on WindowsNT
The method should be in the URI prefix since it really does identify the communication protocol. Save "cvs" for the standard CVS protocol; cvs-p perhaps for pserver, cvs-ssh for SSH, etc. The method name does not belong in the URI body. Then after the // use the standard URI style: user:password@host:port I'm not gonna write the BNF -- here are the rules in prose: Either user or password may be omitted and will default to some value specific to the remote host. If both are omitted, then the initial colon and atsign should also be omitted. The port number is optional and defaults to a value dependant on the URI prefix. If present, it must be preceeded by a colon and followed by a decimal number. (Named ports are a no-no.) After the remote server identification comes the "root" of the CVS repository. If you need to refer to a specific module, use pound sign, the module name, and an optional slash and file name. I don't think that there is a reasonable way to really use this, but URI fragments seems clearly the way to spec it. There are a number of Web-CVS interfaces; snarf their URI syntax for things like branches, revisions, etc. *IFF needed.* Hope this helps. /r$ From rsalz Thu Oct 12 17:22:27 2000 From: "Derek R. Price" [EMAIL PROTECTED] Organization: Open Avenue To: Larry Jones [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: login failure on WindowsNT Date: Thu, 12 Oct 2000 17:01:26 -0400 Larry Jones wrote: cvs://method/user@host:port/cvsroot has a / in the "server" part, which isn't allowed; I'd suggest : instead: Didn't remember that. Ok. cvs://method:user@host:port/cvsroot I was hoping to make both 'user' 'method' optional, so, with an optional port, and leaving room for named ports, a parser won't easily be able to distinguish method:host from host:port Another possibility would be: cvs://:method:user@host:port/cvsroot which looks a little funny, but has the nice property that what comes after the // is exactly a CVSROOT specification. I was thinking this might be the way to go, and it does resolve both the above problems. I hadn't thought it through enough yet to realize that it's parsable and really looks like a pretty standard URL. I think it'd have to be: cvs://[:method:][user[:password]@]host[:port]/cvsroot with '[...]' specifying optional parameters, of course. Hmm. Is there a point to this? The basic use case I can come up with would be an anonymous user running a checkout by clicking on a link. Unfortunately, this URL spec doesn't include a module specification. This weakness extends to branches dates. The logic here is that any checkout you could specify on the command line should be specifiable in a URL. Another weakness seems to be an inability to differentiate between :ext: methods. This could maybe be solved by adding an :ssh: method or, alternately, allowing a method syntax like, :rsh-like-program-name@method:. A bit confusing and inextensible, but it should work. Ok. Back to use cases: Without the ability to specify modules, this URL makes sense for a GUI client such as gCVS and a server with the 'ls' patch to allow browsing. (i.e. The user would click the link in a browser, the browser would pass the URL to gCVS, gCVS would login and allow the user to start browsing available modules. Without the ability to specify modules, this URL could also trigger only a login action when clicked. Then the user would be logged in and it could be left to them to figure out what else to do. Easy for us, but the user is still going to have to retype the URL at some point to initiate their first checkout. They'd also have to type a module name. With extra syntax which provides the ability to specify modules, branches, dates, a user could checkout modules, development branches, and releases from anonymous cvs repositories with a single click. With extra syntax to specify which rsh-like program to use, I could provide a link to an anonymous but secure server for a corporate client. Of course, something that can simply be pasted into CVSROOT seems clean at first glance, but why define a URL if you can't click on it for effect from a browser anyhow? And there seems to be a lot of power in a link that allows a new user to download the tip of a project's dev or stable branch in a single click. Comments? Ideas? Problems? More use cases? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Southern DOS: Y'all reckon? (yep/Nope) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: login failure on WindowsNT
Pradeep Picardo wrote: I have (correctly I believe) set the environment variables CVSROOT and CVS_CLIENT_PORT on my Windows machine. CVS_CLIENT_PORT only works with a hacked version of CVS. Are you sure you have one? I can put up the patch if you want it. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not instigate revolution. I will not instigate revolution. I will not instigate revolution... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: login failure on WindowsNT
Hi, Terribly sorry about that. The version of cvs we are using on unix here has been hacked. I found out about that only last night. I have rebuilt cvs on windows to pick up the port number from the environment the way our unix version does. Should I pass on the code so it can be incorporated into the main distribution ? (Because it does seem like a needless omission to me.) Pradeep. On Wed, 11 Oct 2000, Derek R. Price wrote: Pradeep Picardo wrote: I have (correctly I believe) set the environment variables CVSROOT and CVS_CLIENT_PORT on my Windows machine. CVS_CLIENT_PORT only works with a hacked version of CVS. Are you sure you have one? I can put up the patch if you want it. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not instigate revolution. I will not instigate revolution. I will not instigate revolution... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
