|
Why not upgrade CVS? Subversion, GNU Arch, etc.Why not upgrade CVS? Subversion, GNU Arch, etc.Posted Jun 2, 2004 18:06 UTC (Wed) by robla (subscriber, #424)In reply to: Why not upgrade CVS? Subversion, GNU Arch, etc. by dmarti Parent article: Arch for CVS Users (Linux Journal) Seems like both a blessing and a curse. It makes it simple to set up, but what happens when you want fine-grained access control? That seems like an architectural limiation; either someone has write access to the repository, or they don't. You can't have high confidence in the change auditing mechanisms, since most of the interesting logging/auditing/etc would need to occur in the client. It also means that if there's a security vulnerability, ALL of your users with write access need to upgrade, or the central server itself is compromised. Rob
(Log in to post comments)
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 18:34 UTC (Wed) by moffixx (guest, #22010) [Link] Well, since there is no actual server process, your security is based on the security of your SSH server. This is no different from operation without arch repositories on the machine.There are ways to restrict users to SFTP only, if that's what you're worried about.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 0:58 UTC (Thu) by mbp (guest, #2737) [Link] The most common type of fine-grained access control that you want in SCM is that particular users should be able to commit to particular branches, but not to others. You can easily do this in Arch (or Darcs for that matter) by just setting the permissions on the relevant directory, since each branch is stored in a separate directory. I consider it a feature that it simply uses OS security: if you want ACLs, use a kernel that supports ACLs. If you want SELinux style features, use SELinux. Simplicity helps security.You can also spread branches across machines. Put your main branch on a machine that only the core team can access. Easy. You can't have high confidence in the change auditing mechanisms, since most of the interesting logging/auditing/etc would need to occur in the client. Arch would be an excellent application for the SFTP logging patch. This would give you a strong audit trail of who committed to which branch and when. This is probably stronger than you can manage with CVS or Svn, since the audit log is maintained by root and doesn't directly rely on anything invoked by the user, unlike typical CVS/Svn hooks. It also means that if there's a security vulnerability, ALL of your users with write access need to upgrade, or the central server itself is compromised. That's an issue with Svn and CVS too: if somebody can ssh to your machine and they get rooted then you are at risk. With all three systems you can reduce the risk by using chroots or restricted shells or whatever, but it's still there. So please encourage your developers not to get rooted. Arch allows you to do development without anyone having a login to anyone else's box. This is a major security feature, not supported by either CVS or Svn at the moment.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 4, 2004 0:05 UTC (Fri) by abentley (guest, #22064) [Link] You can't have high confidence in the change auditing mechanisms, since most of the interesting logging/auditing/etc would need to occur in the client. On the contrary, Arch has support for gpg-signed archives. The signing happens client-side, which means you know which archives you can trust even after a server compromise.
|
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds
Powered by Rackspace Managed Hosting.