RE: CVS : extracting releases without the 'CVS related stuffs'
I think you want the command 'cvs export' for the given tag. This does not
give you the CVS directories in the source tree. Stuff like $Id$ and $Log$
tags will remain in the sources though - it's not clear if this is what
you're referring too.
Other than that, I use 'cvs co foo' followed by a 'find foo -type d -name
CVS -exec rm -rf {} ;' :-)
Cheers,
Jan
-Original Message-
From: Thomas Lavergne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 17, 2004 5:53 PM
To: [EMAIL PROTECTED]
Subject: CVS : extracting releases without the 'CVS related stuffs'
Hi all and sorry if this seems a trivial issue : the faq is
of no help.
I would like to checkout a release tagged version of my software, but
without all the 'CVS related stuff'. I just want a directory
with all my
sources and makefiles in order to distribute it. I do not
want copies to
contain the CVS history information. Is there a special command or
option to check-out?
Thanks,
Thomas
___
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: CVS Security Issues
Jim, all, I'll take on a point below: -Original Message- From: Jim.Hyslop [mailto:[EMAIL PROTECTED] Sent: Friday, December 19, 2003 5:19 PM To: 'CVS-II Discussion Mailing List'; 'CVS-II Bugs Mailing List' Subject: RE: CVS Security Issues [stuff deleted...] I.e. please do not pretend you can gain anything by pretending to make the CVSROOT/passwd file harder to mess with. That's a good point - as Bruce Schneier, author of Applied Cryptography and a computer security expert, is fond of saying: Security is only as good as its weakest link. For pserver, access to the passwd file is not the weakest link by any means. Moving the file to a different location will not significantly improve its inherent insecurity. [more stuff deleted ...] The only reason to put the passwords somewhere else is to prevent someone from accidentally checking it out and accidentally changing or deleting someone elses' password and checking the file back in. It's a support issue, not a security one, whether the user intended to change their password or someone elses' is another question entirely. But I think there is a 'gain' here by keeping the passwd file somewhere else where some git can't wipe all the users by accident and bring development to a grinding halt. That's my opinion. On security, you have two types of security anyways: 1) protection against malicious people and 2) protection for your data from accidental damage, deletion, or whatever (protecting users from themselves). CVS is part of category 2, obviously with the support of backup systems and so on. Pserver figures into category 2 because you prevent the users from accidentally working in the actual repository and doing stuff like deleting directories. The keyword here is accidental - either because of ignorance or because one was not thinking about what directory someone happened to be in. I would also argue category 2 is (still) responsible for most data loss in the world today. Your opinion? Seasons greetings, Mr. Jan Walter Chief Architect DEFINIENS AG Trappentreustr. 1; D-80339 München Phone: +49-(0)89-231180-18 Fax: +49-(0)89-231180-90 [EMAIL PROTECTED] http://www.definiens.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Security setup
Larry Jones writes: Mike Ayers writes: Here's a bit of a challenge for the list. We need to set up a CVS repository on a Linux server such that the users can't modify the files, except through proper CVS operations. The catch? They are currently permitted to log into the server. Is there a way to seal off the repository without banning them from logging in? It has not been said that there is no option to prevent login, but if I can avoid that option, it would be preferrable. Suggestions? Rewrite CVS? Seriously, as I've said many times before, CVS was designed to facilitate cooperative work, it was *not* designed to enforce security in any way, shape, or form. Any attempt to make it do so is doomed to fail. I think we need to differentiate between really bullet-proof security and reasonable security - after all, security is also there to protect users from themselves, with no malicious intent required. I would also fathom that this is the cause of most data loss. For Mike I'll detail the environment here - semi-secure, not ill-will proof by any means, but enough to prevent someone from accidentally doing a lot of harm to the repository. The cvsroots live in /home/cvs, owned by user cvs, and group cvs. This directory is only readable by that account. Pserver runs with the cvs user permissions, and each user (whether or not they have a local shell account or not) has a user ID and password for the repository in the CVSROOT/passwd. The format userid:password:cvs in the passwd file, meaning the pserver will not su to the user's id that has logged in, and thus has permissions to the directories and stuff. The password file is not part of the repository (i.e. No ,v file) and so cannot get checked out and broken. The cvsroots are backed up twice a day to a tar file, and the one in the evening gets pushed over to the server with the tape drive for a backup. Bullet-proof? No. Works? Yes. Would I put this setup on the Internet? Absolutely not. - Users cannot fiddle with the ,v files in the repository withouth su'ing to cvs (if they have the password) or root. - Local or remote cvs access possible - Password changes are a pain in the #$% - pserver runs though xinetd, and connections are logged the usual way Now, you could tighten this up a great deal, like block access to the pserver from all but localhost (since it's safe to assume that anyone with shell access is trusted to some extent) and limit your exposure, or require stuff like ssh certificates and all that for external connections. Cheers, Jan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Weird problem, not urgent, just curious
When I do a 'cvs co -D Dec 06 2002 myproject' some files get tossed in that were actually removed from cvs in October. They dont appear in a normal 'cvs co myproject' (obviously the directories do unless I use the prune option). Doing a 'cvs log' command on these files shows them as having been dead, and now having a status of 'Exp;' - the rcs path shows them as living in the attic. What's up with that? We're still using CVS 1.11p1 - maybe that's a quirk that got fixed in 1.12. Next question - any upgrade gotchas? __ Mr. Jan Walter PolyMind PDM DEFINIENS AG Trappentreustr. 1; D-80339 München Phone: +49-(0)89-231180-18 Fax: +49-(0)89-231180-90 [EMAIL PROTECTED] http://www.definiens.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Weird problem, not urgent, just curious
Larry Jones writes: Walter, Jan writes: When I do a 'cvs co -D Dec 06 2002 myproject' some files get tossed in that were actually removed from cvs in October. They dont appear in a normal 'cvs co myproject' (obviously the directories do unless I use the prune option). Doing a 'cvs log' command on these files shows them as having been dead, and now having a status of 'Exp;' - the rcs path shows them as living in the attic. What's up with that? Could you post an example log? It sounds like the files have been partially resurrected -- they're no longer dead, but they're still living in the Attic. Yep, sure looks that way to me too. The thing is, why dont these files come back to life when you do a cvs co without the -D option? RCS file: /home/cvs/cvsroot/Polymind/polymind/src/com/definiens/polymind/service/ontol ogy/anrf/tests/Attic/ANRFinalizerTest.java,v Working file: ANRFinalizerTest.java head: 1.3 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 3; selected revisions: 3 description: revision 1.3 date: 2002/10/21 15:10:56; author: mcarter; state: Exp; lines: +1 -1 tests folder now called _tests revision 1.2 date: 2002/10/21 15:10:56; author: mcarter; state: dead; lines: +0 -0 tests folder now called _tests revision 1.1 date: 2002/10/21 14:25:48; author: mcarter; state: Exp; refactored anrlg, anrf and dmw to sit under ontology = We're still using CVS 1.11p1 - maybe that's a quirk that got fixed in 1.12. Next question - any upgrade gotchas? I think you mean CVS 1.11.1p1 and 1.11.2 -- there is no 1.12 yet. The major problem with 1.11.2 is that it doesn't work in server mode with earlier clients when using compression. If you're considering upgrading, I would actually suggest the current development version instead, or waiting for it to be blessed as 1.11.3 (which shouldn't take too long). Cool. Good advice, thanks. Jan __ Mr. Jan Walter PolyMind PDM DEFINIENS AG Trappentreustr. 1; D-80339 München Phone: +49-(0)89-231180-18 Fax: +49-(0)89-231180-90 [EMAIL PROTECTED] http://www.definiens.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Security setup
Larry Jones writes: Walter, Jan writes: I think we need to differentiate between really bullet-proof security and reasonable security - after all, security is also there to protect users from themselves, with no malicious intent required. I would also fathom that this is the cause of most data loss. I agree. However, I think that CVS's normal configurations are sufficient to provide the latter kind of security and any further efforts to provide more security are misguided and probably a waste of time. Having the repository owned by a single user, for example, only protects against someone accidentally mucking about with the files there, a situation which I've never heard tell of. It's easily subverted with only the slightest of malicious intent, so is it really worth doing? Particularly since doing so removes all traceability, should some have such malicious intent. Well, the cvs logs still have the user info, like who committed it, etc. True, it does not sit in the file system, but does it need to? The reason I set it up here this way was precisely that's _how_ some developers here got rid of files (instead of a cvs remove). At least now it's logged. Jan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Security, audits and pserver
Been watching this thread for a while... Here is my question: Are chrooted environments truly more secure than accessing pserver over an ssh tunnel? Yes, I know you can do both. There was some talk of local user accounts in a chrooted environment are more secure than connecting to pserver for instance. Personally I tend to believe that giving people any sort of local access (even in a chrooted environment for the user for instance) is more of a security risk than allowing pserver access over ssl/ssh, with the limited number of users having the key needed to connect (i.e. Auto-key negotiation disabled and so on). This limits the exposure of pserver to people already having the public key of the server (and their public key registered there). The way I have it set up here is that pserver and the cvsroots run as user cvs, which is an account w/o a shell, but a home directory (the cvsroots). Other users do not have any privileges in the cvs directories. Since the network is trusted, encryption over the network is not necessary here, but it would be possible to set up. The passwd and readers files, while living in the $CVSROOT/CVSROOT directory are not part of the repository (i.e. No ,v files) and so cannot be modified by any users. Advantages: - separate user management per cvsroot via the cvs passwd and readers files (i.e. Local account != cvs access) - optional connectivity with ssh (and potentially limiting access not only by user, but also by valid keys) - users on the local machine do not have read or write access to the repository (except when connecting via pserver too, of course, but the point is that they cannot go in and muck around with the actual files in the repository) Disadvantages: - if someone did a buffer overflow attack and could get a shell, they would have access to the cvsroots (but a chroot environment does not prevent that, it just limits access to other binaries and directories) - obviously, the ssh tunnel is potentially vulnerable to overflow attack - attackers could get the keys needed to attack pserver directly by cracking the accounts of the remote users - changing the user's password requires admin intervention (a huge pain for bigger sites i suppose) Cheers, Jan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 5:21 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: 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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Security, audits and pserver
That's why you would tunnel it over ssh or something like that, with limited key access. People you trust get the key, and their key gets kept on the server. Definitely, a wide-open pserver connection is just an invitation to get cracked. Jan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, December 16, 2002 5:13 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Security, audits and pserver Walter, Jan writes: Personally I tend to believe that giving people any sort of local access (even in a chrooted environment for the user for instance) is more of a security risk than allowing pserver access over ssl/ssh, with the limited number of users having the key needed to connect (i.e. Auto-key negotiation disabled and so on). This limits the exposure of pserver to people already having the public key of the server (and their public key registered there). Note that giving anyone pserver access to a machine is equivalent to giving them local shell access -- there are fairly simple tricks that can be used to execute arbitrary code on the server. CVS was not designed as a security application, it was designed as a collaboration application for cooperative users. -Larry Jones Let's just sit here a moment... and savor the impending terror. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
