| |||||||||||||
|
| |||||||||||||
Why not upgrade CVS? Subversion, GNU Arch, etc.Why not upgrade CVS? Subversion, GNU Arch, etc.Posted Jun 2, 2004 17:00 UTC (Wed) by dmarti (subscriber, #11625)In reply to: Why not upgrade CVS? Subversion, GNU Arch, etc. by drathos Parent article: Arch for CVS Users (Linux Journal) One cool thing about Arch is that it requires zero server-side setup -- you can use a directory on your existing server for Arch without installing any software there. (I went through the steps in Nick's article, and all I had to do on the server was one mkdir and one chmod)
(Log in to post comments)
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 18:06 UTC (Wed) by robla (subscriber, #424) [Link] 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
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.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 18:38 UTC (Wed) by piman (subscriber, #8957) [Link] Subversion can also operate this way if you're only interested in SSH-based access.Both Arch and Subversion require "a lot" of configuration and dependencies if you want fine-grained access controls, e.g. Apache + DAV.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 19:13 UTC (Wed) by mmarsh (subscriber, #17029) [Link] That's why I'd like to see a more active project adopt the OpenCM approach of using SSL and identifying principals with public keys rather than passwords. Having authorized users specified as "Alice keys/alice.pubkey" and not requiring any further knowledge of Alice on the server would make life much easier for collaborations. Add SPKI/SDSI-type delegation and you could reduce the server-side access control to the public key of the repository owner (who might not even have an account on the machine), but this is probably overkill for a typical CM system.This would be perfect for people who don't have root, and consequently can't add users, and run the server under their own UID. It would also be easier than giving people accounts, though you'd have to worry about the security of the CM software.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 23:21 UTC (Wed) by piman (subscriber, #8957) [Link] I'm no expert in PKI (or Apache), but I think Apache can already authenticate like that.I know that with Apache (or svnserve) you can easily let users define their own authorization schemes, which don't rely on local logins.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 0:04 UTC (Thu) by mmarsh (subscriber, #17029) [Link] Apache certainly can, but that's kind of a heavyweight solution for a CM server. svnserve has a similar feature to pserver, except that passwords are never sent over the wire, but are used in a cryptographic hash. Unfortunately, the passwords are stored in cleartext. I just can't bring myself to use anything that stores cleartext passwords. Given how (relatively) easy OpenSSL is to use, it's surprising that there only seems to be one CM that takes advantage of it (not counting Subversion+Apache).Of course, the right thing to do would be to offer to help Subversion add SSL/TLS to the stand-alone server.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 1:02 UTC (Thu) by mbp (guest, #2737) [Link] Both Arch and Subversion require "a lot" of configuration and dependencies if you want fine-grained access controls, e.g. Apache + DAV.I don't think that is true for Arch. I have different branches with different visibility simply by publishing them on public web sites, private web sites, or not at all. I don't allow anyone to directly commit to my archives and that works fine. There is no DAV involved, and only Apache 1.3. What configuration do you suppose is needed? (Congratulations on spelling "a lot" correctly though. It certainly raises the tone compared to Slashdot. :-)
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 6:22 UTC (Thu) by piman (subscriber, #8957) [Link] I don't consider flat-out refusing others to commit to your archive fine-grained. I do realize that it fits much better with some of the development models supported by Arch, and so is a more realistic possibility than with Subversion (where such a situation would essentially result in no developers sharing revision information at all).Personally I see value in having many people able to commit to the same repository. This can be done with Arch or Subversion, but it requires more configuration than just SSH to do properly for both of them. To say that Arch doesn't require any server configuration (like dmarti) did is technically true, but you can make the same claim for SVN - in both cases, for the limited, one-committer, private archive situation. Even in your case, there's some server configuration involved in publishing the Arch changesets appropriately.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 6:31 UTC (Thu) by mbp (guest, #2737) [Link] So what do people mean by "fine-grained"? Finer than branches? Do you want to limit which directories or files can be touched?The thing is this: anyone who I would trust to have SSH access to my machine and to commit to a branch, I would trust to commit to any file within that branch. If they suddenly turn bad, being able to commit anywhere is enough to cause trouble. I can't think of many cases where I want to allow people to write to only particular files in a project. I can certainly imagine people only being able to write to one project and not another, or to one branch but not another. But Arch accomodates those uses just fine, and without requiring as much configuration as Svn. Just chgrp/chmod the directory and you're done. > This can be done with Arch or Subversion, but it requires more I don't think that's correct. What were you thinking of?
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 6:44 UTC (Thu) by piman (subscriber, #8957) [Link] (I realize that one significant thing I was forgetting was that in Arch, branches are not (necessarily) directories. In Subversion, they are, and I was conflating branch permissions with directory permissions unconsciously. Sorry.)I am more interested in the case where I am some user on a system, without root access. I have some repository/project that the admin has set up for me, and I want to be able to authorize people to read from and commit to it. I want to do this as easily as possible, without having to bug the admin whenever I want to change a user's permissions. I cannot see a way to do this with Arch or Subversion, period, without setting up some sort of (non-SSH) server. One serious problem any SCM will run into with SSH-based access, at least if it is used on huge "communities" like SourceForge, is that Linux only allows 32 groups per user. I can't really fault Arch for this, but it does mean that some alternate authentication methods will have to be looked at.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 8:02 UTC (Thu) by mbp (guest, #2737) [Link] Ah, OK. So with subversion, people can write through the DAV module and be authenticated as a user that does not exist as a system user. That is a good feature.I think setting that up to be secure is going to be more work than configuring either svn+ssh or arch+ssh, and I personally would feel less comfortable that it is secure. Although Arch does not take this quite as far as Subversion, it does not require one OS-level uid per committer. For something like SF, you might be better off with one uid per project, and multiple SSH keys. I can think of a few ways to solve your problem, depending on the details. The first question would be, why do you want other people to be able to commit to the repo? Let's suppose the answer is that you have several developers, you all trust all each others changes and nobody wants to be the gatekeeper or integrator. What I would probably do is let every developer have their own archive. On the "head" archive, I would have a script that regularly tries to pull in changes from each developer, and maybe only commits to head if they compile/pass the test/whatever. I guess with Subversion you could set up your own DAV server on a high-numbered port, but frankly I'm not sure that is something you should be doing without the administrator's permission. Most admins on net-connected machines don't appreciate it when people start complex servers listening for connections without the admin's permission. You could get to a similar situation with Arch by running your own ftp server on a high-numbered port, limited to the appropriate directory. I would be a bit nervous about doing that, but it is not inherently any more risky than the Svn server. This would let people directly commit to the archive, etc. (Can you start sshd as non-root? The protocol would allow it in principle, but I don't know if it works...) > One serious problem any SCM will run into with SSH-based access, Right, and SF hit this bug with CVS a while ago. I think the whole idea of having one machine with tens of thousands of users is pretty bad to start with. The security implications are horrible, and in fact I read some project's horror story the other day about a rogue user deleting their files. With Arch you don't *have* to have one centralized machine for the whole world. It solves the SF problem at a deeper level.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 11:15 UTC (Thu) by job (subscriber, #670) [Link] ACLs? (Rant below.)
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 12:40 UTC (Thu) by Wol (guest, #4433) [Link] Nobody's mentioned BitKeeper ... it sounds to me like Arch is meant to be similar in principle.I do not want ANYONE updating my archive. And the central project archive should only be updated by ONE person (or a group agreeing amongst themselves). Linus uses BitKeeper because he can give everyone *read* access to his tree and they keep themselves up-to-date. He has *read* access to other peoples' trees and can update his system from theirs as he sees fit. I get the impression Arch is designed to work the same way - you need one person keeping the master repository up-to-date by *pull*ing from the developers, and the developers keeping up-to-date by *pull*ing from the master. If you think in CVS terms you won't understand what the hell is going on, because CVS is a *push* system - the deverloper pushes updates to the central repository. Cheers,
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 4, 2004 1:46 UTC (Fri) by josh_stern (guest, #4868) [Link] I hate to sound ungrateful and demanding, but for using the pullmodel it would be nice to have an integrated email push of the comment logs. I'm not familiar whether bitkeeper provides such but I haven't come across such a thing in the docs for arch. Yeah, I know it wouldn't be too hard to hack up an alternative interface for oneself...so I'm just giving feedback that this would be a desirable feature add-on.
|
|
||||||||||||