Feature request/ideas
In response to an old thread/message from dec 04, (http://lists.gnu.org/archive/html/bug-cvs/2004-12/msg00150.html) I would like to add some suggestions: The cvsnt commitid feature for the log cmd is a very neet feature because it allows to collect all versions that belong to a single commit. Another idea is a diff extension: Set to a specific revision (using the diff -r option), I would like to compare this revision against its direct parent. Any comments? Regards Frank ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
CVS build fails with --disable-client option
$ ./configure --disable-client $ make ... if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../lib -I../diff -I../zlib -I/usr/kerberos/include -Ino/include -g -O2 -MT edit.o -MD -MP -MF .deps/edit.Tpo -c -o edit.o edit.c; \ then mv -f .deps/edit.Tpo .deps/edit.Po; else rm -f .deps/edit.Tpo; exit 1; fi edit.c: In function `edit_fileproc': edit.c:350: error: structure has no member named `isremote' make[2]: *** [edit.o] Error 1 ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Windows POSIX
Hi Conrad, On Tuesday 22 February 2005 04:34, Conrad T. Pino wrote: How does abstracting all CVS I/O calls for files, pipes and sockets sound to you? Emulating non-blocking I/O (including select()) with Windows API functions (asynchronous ReadFile()/WriteFile() and WaitForMultipleObjects()) is a nightmare. For instance a) you cannot cancel an asynchronous ReadFile() operation and then reliably determine the amount of data already read. b) cancelling a ReadFile() operation (via CancelIo()) automatically cancels any other I/O operation on the same handle c) you cannot determine the amount of data which can be read immediately (without blocking) for all kinds of input sources. Non-blocking writing has its own problems. Maybe there is an easy solution for this, but I have not yet found it. Kind regards Ingolf -- Ingolf Steinbach Jena-Optronik GmbH [EMAIL PROTECTED] ++49 3641 200-147 PGP: 0x7B3B5661 213C 828E 0C92 16B5 05D0 4D5B A324 EC04 ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Windows POSIX
Maybe there is an easy solution for this, but I have not yet found it. What about taking some code/adapt code from cvsnt? I have not taken a detailed look at it, but there must already be some abstraction done ... Frank ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: FAQ-O-Matic pserver protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones wrote: | Guus Leeuw jr. writes: | | I take this as a veto for no switches, but merely cvs passwd | which would run only: a) if pserver protocol b) the user in | questo is listed in CVSROOT/passwd on the pserver | | | I don't even like the idea of doing that, but I won't veto it if | Derek and Mark think it's a good idea. Given the security deficiencies already inherent in the pserver protocol, I can't see much harm in allowing passwords to be changed via a CVS interface. Requiring a user to type perl in on the shell command line to change a CVS password doesn't seem to me to add much additional security when the passwords are already so easily compromised. Might as well allow users who have already decided pserver is secure enough for them the convenience of a passwd interface. Hrm. Then again, the more I consider the implications of a `cvs passwd' command, the less appealing it sounds. Firstly, in the recommended pserver configuration, if you fail to heed all the dire warnings we provide about pserver in the first place, the CVS team recommends that the CVSROOT module only be writable by members of some cvs admin group, perhaps `cvsadmin', since otherwise anyone could check in a CVSROOT/passwd file, add it to CVSROOT/checkoutlist, and overwrite your passwd file, mapping their account to any user on the system that they wished, other than root. To work around this in such a way as to allow any user to change their own password, a few possible solutions come to mind. The cvs pserver would need to either keep root privileges longer than it currently does, an option which is definitely out or, alternatively, perhaps a second `cvspasswd' executable with setgid cvsadmin privileges could be installed. This sounds slightly more secure, but still opens the possibility of new weaknesses in the `cvspasswd' executable. Perhaps some reasonable compromise could be reached, possibly involving relocation of the CVS passwd file into /etc/cvs/ or somesuch as has been suggested in the past, but most of what I can come up with still involves the potentially dangerous setgid executable. The stated position of the CVS team has been to recommend using some sort of :ext:/ssh access combination using system userids when security is a concern. This is an acknowledgement that CVS gets few security audits and it is best to rely on tools that do get thorough security audits for CVS access. This also saves on the time of the CVS maintainers by allowing us to leverage existing tools where security is concerned. I am still willing to discuss this matter, particularly because my personal design philosophy tends to favor new features as progress, with faith that the problems in a new design will be discovered and solved later, but, at the risk of sounding stifiling, the potential for new security issues arising in the already flawed pserver design is real and I think these issues need to be addressed before anything like this should be adopted. Then again, perhaps the right approach would be to allow the passwd command but continue to recommend clamping down permisions on CVSROOT such that it can't be used. This does sounds like a contradictory position, though, and might help mislead naive and beginning users. I guess I'm with Larry, at least until these issues are satisfactorily addressed. Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCG1eULD1OTBfyMaQRArD0AJ9cBZ0gstVvKuOiKQ1zGtx9wzorbQCg05zb lzv3Z0v2G1kjQB1m4+Hntj0= =PVTD -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: CVS Feature Branch - Windows Build Broken - run_add_arg, run_piped
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: | The following patch fixes all build errors. | | I don't claim it works and I don't claim it doesn't work. | | It's a good guess and I'd appreciate feedback before committing. It looked good and I committed it. Thanks for noticing strtok is unneeded. I'm installing that in src too. Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCG2EYLD1OTBfyMaQRAhymAJ95eRtkjJuvSkdggD7/zf3JGlhC7ACg1iDT oqCsUnX/yqmSKe3LPNB3+kQ= =xo2X -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: CVS Feature Branch - Windows Build Broken - run_add_arg, run_piped
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price wrote: | Thanks for noticing strtok is unneeded. I'm installing that in src | too. Er, I thought I saw that there was an extra strtok decl in src too, but I guess not. Thanks regardless. Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCG2GrLD1OTBfyMaQRAsZQAKDm8DdEhvPluUGox8dw31ErYVUgAACeP49g ALfrHVSUOt6FwEwsUfzMviQ= =/HY1 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: lines modified in newly-added files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neil Conway wrote: | Derek Price wrote: | | You will need to count the total number of lines in the HEAD | revision and keep it up to date as added and deleted lines for | other revisions are processed. Later, in `cvs log', these new | fields should be usable in conjunction with added and removed | lines to get the output you are after. | | | Ah, I see. Thanks very much for the detailed explanation of the | issues involved -- I'll take a look at implementing this, and get | back to you. You're welcome. I'm looking forward to seeing a patch! Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCG2T1LD1OTBfyMaQRAvreAKCTZH0tKWqyDGMYEex7T5oGXByBrQCfcGzS CFxVmfBd30/xvh6NNVB7I28= =yv9H -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Changing passwords for CVS Users (pserver protocol)
Derek Price wrote: The patch does what you said it would on stable, but something else is wrong on feature. The new watch6-2 test fails - basically, the previous watch add appears to be failing without reporting the error. I've attached a revised patch, with the failing tests (which, again, pass on stable). OK, I'll look into the problems on feature. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: FAQ-O-Matic pserver protocol
Derek Price wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones wrote: | Guus Leeuw jr. writes: | | I take this as a veto for no switches, but merely cvs passwd | which would run only: a) if pserver protocol b) the user in | questo is listed in CVSROOT/passwd on the pserver | | | I don't even like the idea of doing that, but I won't veto it if | Derek and Mark think it's a good idea. Given the security deficiencies already inherent in the pserver protocol, I can't see much harm in allowing passwords to be changed via a CVS interface. Requiring a user to type perl in on the shell command line to change a CVS password doesn't seem to me to add much additional security when the passwords are already so easily compromised. Might as well allow users who have already decided pserver is secure enough for them the convenience of a passwd interface. Hrm. Then again, the more I consider the implications of a `cvs passwd' command, the less appealing it sounds. Firstly, in the recommended pserver configuration, if you fail to heed all the dire warnings we provide about pserver in the first place, the CVS team recommends that the CVSROOT module only be writable by members of some cvs admin group, perhaps `cvsadmin', since otherwise anyone could check in a CVSROOT/passwd file, add it to CVSROOT/checkoutlist, and overwrite your passwd file, mapping their account to any user on the system that they wished, other than root. To work around this in such a way as to allow any user to change their own password, a few possible solutions come to mind. The cvs pserver would need to either keep root privileges longer than it currently does, an option which is definitely out or, alternatively, perhaps a second `cvspasswd' executable with setgid cvsadmin privileges could be installed. This sounds slightly more secure, but still opens the possibility of new weaknesses in the `cvspasswd' executable. Perhaps some reasonable compromise could be reached, possibly involving relocation of the CVS passwd file into /etc/cvs/ or somesuch as has been suggested in the past, but most of what I can come up with still involves the potentially dangerous setgid executable. The stated position of the CVS team has been to recommend using some sort of :ext:/ssh access combination using system userids when security is a concern. This is an acknowledgement that CVS gets few security audits and it is best to rely on tools that do get thorough security audits for CVS access. This also saves on the time of the CVS maintainers by allowing us to leverage existing tools where security is concerned. I am still willing to discuss this matter, particularly because my personal design philosophy tends to favor new features as progress, with faith that the problems in a new design will be discovered and solved later, but, at the risk of sounding stifiling, the potential for new security issues arising in the already flawed pserver design is real and I think these issues need to be addressed before anything like this should be adopted. Then again, perhaps the right approach would be to allow the passwd command but continue to recommend clamping down permisions on CVSROOT such that it can't be used. This does sounds like a contradictory position, though, and might help mislead naive and beginning users. I guess I'm with Larry, at least until these issues are satisfactorily addressed. I have plans to impliment pserver with ssl support, it doesn't seem too awful. Would there be any takers? /Brian ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: FAQ-O-Matic pserver protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Murphy wrote: | Derek Price wrote: | | -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | | Larry Jones wrote: | | | Guus Leeuw jr. writes: | | I take this as a veto for no | switches, but merely cvs passwd | which would run only: a) if | pserver protocol b) the user in | questo is listed in | CVSROOT/passwd on the pserver | | | I don't even like the idea of | doing that, but I won't veto it if | Derek and Mark think it's a | good idea. | | | Given the security deficiencies already inherent in the pserver | protocol, I can't see much harm in allowing passwords to be | changed via a CVS interface. Requiring a user to type perl in on | the shell command line to change a CVS password doesn't seem to | me to add much additional security when the passwords are already | so easily compromised. Might as well allow users who have | already decided pserver is secure enough for them the convenience | of a passwd interface. | | Hrm. Then again, the more I consider the implications of a `cvs | passwd' command, the less appealing it sounds. Firstly, in the | recommended pserver configuration, if you fail to heed all the | dire warnings we provide about pserver in the first place, the | CVS team recommends that the CVSROOT module only be writable by | members of some cvs admin group, perhaps `cvsadmin', since | otherwise anyone could check in a CVSROOT/passwd file, add it to | CVSROOT/checkoutlist, and overwrite your passwd file, mapping | their account to any user on the system that they wished, other | than root. | | To work around this in such a way as to allow any user to change | their own password, a few possible solutions come to mind. The | cvs pserver would need to either keep root privileges longer than | it currently does, an option which is definitely out or, | alternatively, perhaps a second `cvspasswd' executable with | setgid cvsadmin privileges could be installed. This sounds | slightly more secure, but still opens the possibility of new | weaknesses in the `cvspasswd' executable. | | Perhaps some reasonable compromise could be reached, possibly | involving relocation of the CVS passwd file into /etc/cvs/ or | somesuch as has been suggested in the past, but most of what I | can come up with still involves the potentially dangerous setgid | executable. | | The stated position of the CVS team has been to recommend using | some sort of :ext:/ssh access combination using system userids | when security is a concern. This is an acknowledgement that CVS | gets few security audits and it is best to rely on tools that do | get thorough security audits for CVS access. This also saves on | the time of the CVS maintainers by allowing us to leverage | existing tools where security is concerned. | | I am still willing to discuss this matter, particularly because | my personal design philosophy tends to favor new features as | progress, with faith that the problems in a new design will be | discovered and solved later, but, at the risk of sounding | stifiling, the potential for new security issues arising in the | already flawed pserver design is real and I think these issues | need to be addressed before anything like this should be adopted. | | | Then again, perhaps the right approach would be to allow the | passwd command but continue to recommend clamping down permisions | on CVSROOT such that it can't be used. This does sounds like a | contradictory position, though, and might help mislead naive and | beginning users. I guess I'm with Larry, at least until these | issues are satisfactorily addressed. | | I have plans to impliment pserver with ssl support, it doesn't seem | too awful. Would there be any takers? I would definitely favor pserver with SSL support as an improvement over vanilla pserver. If you do implement this, please see what you can do about remaining compatible with CVSNT's SSL pserver mode (sserver?). This would not change the `cvs passwd' command issues, however. A secure CVSROOT dir (which is necessary to prevent just anybody from overwriting the CVSROOT/passwd file as things stand) still either prevents `cvs passwd' from running or opens another potential security hole. I might be interested in seeing the setgid `cvspasswd' executable, though. Such a beast might be small enough to make auditing fairly easy and should require few changes once it stabilizes. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCG6fFLD1OTBfyMaQRAvW8AJ0UlX+jawNnq/CsnIvZU5QE3Y1hJwCgk6Qg dr08Y/w/VDwsvtzWqg6uzzU= =9dXO -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
