Re: security question
One other problem with pserver is that passwords are stored in the clear on the users' home directories. At least with SSH, the keys can be encrypted using a password that the user enters either upon login or on a per-use basis. Noel --- Steven Tryon [EMAIL PROTECTED] wrote: We run pserver on a machine behind a firewall and access with redirected ports with ssh. Someone posted on this list a cookbook ssh command to do so... ssh [EMAIL PROTECTED] -L 2401:host.whatever.com:2401 Then set your CVSROOT to point to localhost. Works. Steve On Thu, 2002-12-12 at 10:51, Phil R Lawrence wrote: I saw in the docs how to set up pserver and how it can manage read-write permissions. But I won't run a server without encryption. -- Steven Tryon, ciber @ Xerox Webmaster, Xerox Global Service Net 8*227-1898 / 585-427-1898 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Security, audits and pserver
--- Paul Sander [EMAIL PROTECTED] wrote: A chroot environment is only good at containing what's inside it. It does not prevent access to the chroot environment from outside. I see. I guess it's obvious that the repository would have to be within the chroot'ed environment meaning that such an environment wouldn't help in preventing users from directly accessing the archive files. Is this right? Thanks, Noel __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: security question
One other problem with pserver is that passwords are stored in the clear on the users' home directories. At least with SSH, the keys can be encrypted using a password that the user enters either upon login or on a per-use basis. Actually, if you setup your ssh keys correctly (ssh-keygen -t dsa), then you never have to enter your password at all. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVSROOT must be an absolute pathname problem
On the command line, I get the following problem: GANDALF:/cygdrive/c cvs init cvs init: CVSROOT must be an absolute pathname (not `c:/cygwin/home/Mark/src/master') cvs init: when using local access method. cvs [init aborted]: Bad CVSROOT: `:local:c:/cygwin/home/Mark/src/master'. My environment looks like this: OS: Windows XP Pro Bash version 2.05b.0(8)-release Cvs version 1.11.2 export CVSROOT=:local:c:/cygwin/home/Mark/src/master I am also using wincvs version 1.2. This seems to function properly, but I miss my command line immensely. Any thoughts? Mark Scoville [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: last log entry
Schwenk, Jeanie writes: log was yielding way too much data even with the flags available I could find no way to get a small amount of information - the last log entry being the most important. If you thought rlog was a synonym for log, why did you expect its output to be any different? Try: cvs log -N -rHEAD file -Larry Jones I like maxims that don't encourage behavior modification. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: security question
Steven Tryon wrote: On Thu, 2002-12-12 at 10:51, Phil R Lawrence wrote: I saw in the docs how to set up pserver and how it can manage read-write permissions. But I won't run a server without encryption. We run pserver on a machine behind a firewall and access with redirected ports with ssh. Someone posted on this list a cookbook ssh command to do so... ssh [EMAIL PROTECTED] -L 2401:host.whatever.com:2401 Then set your CVSROOT to point to localhost. OK. I can follow the cookbook above for client access from windows and linux, but how can I establish that same mapping for developers when they are already logged onto the machine with the repository? i.e., how can a developer on localhost log into the pserver using SSH? Phil PS: Does this look right? /etc/passwd: lskywalk:x:600:600:Luke Skywalker:/home/lskywalk:/bin/bash cvs-lsky:x:601:601:Luke Skywalker:/home/usr/local/cvs:/bin/false askywalk:x:600:600:Anakin Skywalker:/home/askywalk:/bin/bash cvs-asky:x:601:601:Anakin Skywalker:/home/usr/local/cvs:/bin/false /etc/group: cvs-fooproj:x:600:cvs-lsky cvs-barproj:x:600:cvs-lsky,cvs-asky CVSROOT/passwd: lskywalk:nn:cvs-lsky askywalk:nn:cvs-asky THEN: # chgrp -R cvs-fooproj /usr/local/cvs/fooproj # chmod g+srwx /usr/local/cvs/fooproj # chmod o+rx /usr/local/cvs/fooproj # chmod o-w /usr/local/cvs/fooproj ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Security, audits and pserver
A chroot environment is only good at containing what's inside it. It does not prevent access to the chroot environment from outside. I see. I guess it's obvious that the repository would have to be within the chroot'ed environment meaning that such an environment wouldn't help in preventing users from directly accessing the archive files. Is this right? Yes, this you are correct... chrooting a file system would have no impact on the user's ability to access the repository. The best method for keeping folks out is to use public key ssh auth, constrain user's key to exactly one command required for cvs, and to disable passwd authentication-- both on the ssh and os level. From this point you can use unix file and group security to further control what can be written/read. I've not set up cvs readers/writers, but that may add an additional layer. Finally, you can implement a commit hook to further filter by module and or branch. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT must be an absolute pathname problem
Mark Scoville writes: GANDALF:/cygdrive/c cvs init cvs init: CVSROOT must be an absolute pathname (not `c:/cygwin/home/Mark/src/master') cvs init: when using local access method. cvs [init aborted]: Bad CVSROOT: `:local:c:/cygwin/home/Mark/src/master'. Try using :local:/cygdrive/c/cygwin/home/Mark/src/master instead. -Larry Jones I don't need to do a better job. I need better P.R. on the job I DO. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVSROOT must be an absolute pathname problem
Thank-you. After resetting CVSROOT (CVSROOT=:local:/cygdrive/c/cygwin/home/Mark/src/master), cvs init returned the following: cvs init: syntax error in /cygdrive/c/cygwin/home/Mark/src/master/CVSROOT/config' is missing '=' Subsequent cvs init's from c:/ runs without error - but ONLY in c:/ Performing a cvs init or any other cvs command from any other directory continues to render: GANDALF:/cygdrive/c/ensignInternet cvs up cvs update: CVSROOT must be an absolute pathname (not `c:\cygwin\home\Mark\src\m')ter cvs update: when using local access method. '.s [update aborted]: Bad CVSROOT: `:local:c:\cygwin\home\Mark\src\master I am not sure why the ter shows up following the close paren above. And the .s is confusing as well. Mark. -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 9:35 AM To: Mark Scoville Cc: [EMAIL PROTECTED] Subject: Re: CVSROOT must be an absolute pathname problem Mark Scoville writes: GANDALF:/cygdrive/c cvs init cvs init: CVSROOT must be an absolute pathname (not `c:/cygwin/home/Mark/src/master') cvs init: when using local access method. cvs [init aborted]: Bad CVSROOT: `:local:c:/cygwin/home/Mark/src/master'. Try using :local:/cygdrive/c/cygwin/home/Mark/src/master instead. -Larry Jones I don't need to do a better job. I need better P.R. on the job I DO. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT must be an absolute pathname problem
Mark Scoville writes: cvs init: syntax error in /cygdrive/c/cygwin/home/Mark/src/master/CVSROOT/config' is missing '=' That implies that you already had a CVSROOT/config file (normally, init would have create it), the contents of which are not valid. Performing a cvs init or any other cvs command from any other directory continues to render: GANDALF:/cygdrive/c/ensignInternet cvs up cvs update: CVSROOT must be an absolute pathname (not `c:\cygwin\home\Mark\src\m')ter cvs update: when using local access method. '.s [update aborted]: Bad CVSROOT: `:local:c:\cygwin\home\Mark\src\master If you're running in a checked-out directory, CVS uses the root stored in the CVS/Root file rather than what the $CVSROOT environment variable is set to. The above messages show the classic symptoms of line-ending problems. If you're using both cynwin CVS and WinCVS, you need to make sure that both are set to use the same line ending conventions (either DOS or Unix); right now, it looks like they're different. -Larry Jones It's hard to be religious when certain people are never incinerated by bolts of lightning. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Determining status
I've noticed that cvs status is able to determine if a file is up to date or locally modified very quickly, i.e., in much less time than would be required to extract the file from the repository and do a comparison. How is this done? Is there some checksum stored away somewhere that is used for the comparison? Chris GE Global Research Center ___ ___ Dr. Christopher R. Volpe, Ph.D. Computer Scientist Visualization and Computer Vision Lab Imaging Technologies Bldg KW, Room C215 P.O. Box 8, Schenectady, NY 12301 (518) 387-7766, Dial Comm: 8*833-7766, Fax: (518) 387-6981 e-mail: [EMAIL PROTECTED]web: http://www.crd.ge.com/~volpecr ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Determining status
On Fri, 13 Dec 2002, Volpe, Christopher R (Research) wrote: I've noticed that cvs status is able to determine if a file is up to date or locally modified very quickly, i.e., in much less time than would be required to extract the file from the repository and do a comparison. How is this done? Is there some checksum stored away somewhere that is used for the comparison? Look in CVS/Entries ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: last log entry
One of the google posts said that within cvs it was a synonym for rlog. But I couldn't find anything regarding that in the cederqvist. Thanks. Jeanie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 8:10 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: last log entry Schwenk, Jeanie writes: log was yielding way too much data even with the flags available I could find no way to get a small amount of information - the last log entry being the most important. If you thought rlog was a synonym for log, why did you expect its output to be any different? Try: cvs log -N -rHEAD file -Larry Jones I like maxims that don't encourage behavior modification. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Determining status
Volpe, Christopher R writes: I've noticed that cvs status is able to determine if a file is up to date or locally modified very quickly, i.e., in much less time than would be required to extract the file from the repository and do a comparison. How is this done? Is there some checksum stored away somewhere that is used for the comparison? Not a checksum, but a timestamp (in CVS/Entries). If the file's current timestamp matches the stored timestamp, it's unmodified. -Larry Jones I've got an idea for a sit-com called Father Knows Zilch. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Security, audits and pserver
--- Forwarded mail from [EMAIL PROTECTED] --- Paul Sander [EMAIL PROTECTED] wrote: A chroot environment is only good at containing what's inside it. It does not prevent access to the chroot environment from outside. I see. I guess it's obvious that the repository would have to be within the chroot'ed environment meaning that such an environment wouldn't help in preventing users from directly accessing the archive files. Is this right? This is correct, provided the users (or other services) aren't confined to their own (non-overlapping) chroot environments. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvsweb.cgi ?
Hello, anyone around who could help me with the following cvsweb.cgi problem: I managed to install cvsweb.cgi (wasn't that hard ;-)), but now selecting a directory leads me into the directory an gives me the following NOTE: NOTE: There are 3 files, but none matches the current tag () The behaviour of my cvsweb.cgi-installation differs from the installation used in webmin v1.010 where a list of tags is display under the files of a directory... my installation doesn't show any tags (maybe this is a hint for someone here ?) chears, Michael ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: security question
--- Zieg, Mark [EMAIL PROTECTED] wrote: One other problem with pserver is that passwords are stored in the clear on the users' home directories. At least with SSH, the keys can be encrypted using a password that the user enters either upon login or on a per-use basis. Actually, if you setup your ssh keys correctly (ssh-keygen -t dsa), then you never have to enter your password at all. Password-protected keys help protect them against theft. I would encourage everyone to use such keys. Or did I misunderstand your post? Noel __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
