> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. > Baushke > Sent: dimanche 13 février 2005 10:54 > To: Guus Leeuw jr. > Cc: info-cvs@gnu.org > Subject: Re: FAQ-O-Matic pserver protocol > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Guus Leeuw jr. <[EMAIL PROTECTED]> writes: > > Have you considered moving to the CVSNT fork of CVS? (Yes, it runs on > boxes other than Windows.)
No, and I won't. I am a long time believer of CVS pure ;) > > > In general, my personal opinion is that the pserver and kserver > > > protocols should be removed from the cvs sources completely. It is > never > > > secure to run the cvs executable as root which is required to use the > > > pserver protocol. The cvs sources were never designed with security in > > > mind and running them as root is idiocy. (Just say no.) > > > > You're kidding right? Root is a good user(TM), no? > > Actually, no, I am not kidding. Well, I was ;) > If you look at the main page (https://www.cvshome.org/) you will see > that even cvshome.org was subject to an attack on a cvs security > violation. Yeah, I've seen that coming along. > If cvs runs as root and allows connections on port 2401, then it had > better be very well audited and have a very tighly written security > model for dealing with all of its inputs and avoid all possibility of a > privilege escallation that results in abuses to that connection. > > There is too much #ifdef'd code and hard to semantically verify code in > the current pserver code path for any sane security expert to give > anything better than an 'unsecure' rating to it. > > One way to deal with this problem would be to do something like OpenSSH > does with priviledge separation, so that only a tiny fraction of well > tested and closely examined code will ever run as root and that it > carefully performs its authentication checks and validations. Further, > it would not provide for a password that is only obscured on the wire, > but is otherwise transmitted in the clear for use in any kind of replay > attack you wish to imagine. Hmm... Good idea... Takes a long time to implement, though... See below. > > Sure enough... What about the people that do use pserver, and want their > > users to change their passwords from CVSROOT/passwd? > > If they are going to move to cvs 1.12.x, then the could go ever further > down the road to perditions flame and use PAM authentication and change > their password via a NIS protocol if they want. I'd assume most people out there use the CVS 1.11 branch of things, so I'd stick passwd in the feature release for the hard-edge to test, and then maybe a back-port? > > No change today... Not securely, that is. > > Hmmm... that really is very funny. Sending the password in a completely > reversible encoding otherwise in the clear to do normal operations is > secure? True, but such is the nature of pserver by default. > > So we might consider implementing it, no? > > I can't stop you. Well, if I'd do it, I'd do it because of: 1) It seems useful (Jim suggested such) 2) Larry, Derek, and you Mark would want it in the general CVS... > > Simply sending a scrambled password over the *LAN* can't hurt too > > much... For WAN, pserver is quite different ;) > > Well, the distance from a LAN to a WAN is a lot smaller than you might > believe. Sure, but LAN is controllable... WAN is not so much controllable... > > Anyways... Development stopped until verdict is received ;) > > CVS is open source. There is nothing to say that you might not provide > whatever patches you want to them and make them available to whoever > wants them. Yeah, again, I'm not going to devote my time to CVS development, when I'm already certain the code's not gonna make it... That seems fair to me ;) > That said, if you really are planning to cleanup pserver to make it > 'secure' for changing a password, maybe you can find the time to do a > more secure replacement code base for the pserver implementation > instead? If you can get security folks to go thru all possible code > paths and shake out the next big bug (and fix it), then I am sure > a lot of folks would appreciate your work. Maybe... We'll see. Let me first tackle the password stuff, and later, I might have time to go about pserver in general... > A strong believer in 'cvs password' should go and look at what CVSNT > does. They already implement a 'cvs password' command. The protocol > element they added is "passwd" so if you use that token in any code you > submit to the CVS version from cvshome.org, then you MUST follow their > protocol exchange rather than implement your own for CVS). We have tried > very hard to ensure that nothing they add or we add will break the basic > compatibility of a mixed client/server with CVSNT and CVS acting as > either role. > > You will want a copy of the cvsnt sources. It may be fetched here: > > cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/cvs co cvsnt > > you would need to look at the cvsnt/src/passwd.c sources for their > implementation. The cvsnt/doc/cvsclient.texi file has their > documentation for the 'passwd' command protocol. Yeah, that sounds like a fair start. Guus -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/02/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/02/2005 _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs