But this doesn't provide the fine-grained access control that the HTTP access method does you just have users who can commit, and users who cannot. The alternative was svnserve, and tunnelling it over SSH. (Well, unless it gets swapped out but I encrypt my swap partition!) Sending passwords over HTTPS isn't too bad, but to obtain one-touch authentication you still need to cache your passwords on disk at the client end ssh-agent is superior because it never saves all the required authentication information to disk. The HTTP-based access methods didn't suit me: I'm probably unfairly biased in favour of SSH, but I couldn't find any supported authentication mechanisms which were as good as ssh-agent. So I was rather hoping Subversion could do better. But at least you know when you're doing that CVSROOT scripts seem more dangerous to me since not every CVS user even needs to know they're there.) (To be fair, version control in some sense inherently requires participants to trust one another, since each one checks in code which the others usually just compile and run. Added to that, there's the question of scripts in CVSROOT (run under each client's UID, so that they can't impose dependable restrictions because hacked clients can bypass them, and conversely if anyone manages to check in a malicious script then all clients will start running it under their own UIDs and propagating malware) and then there's the issue of needing write permission in a directory to read it (although this can be fixed by correct repository administration, i.e. Now just occasionally you do actually want to do things like that (suppose you accidentally checked your password file into a repository, for example – you really would want to remove it from your CVS history, perhaps with a marker explaining what you'd done, rather than just checking in a subsequent change that deleted it) but it certainly isn't clear that allowing all users unrestricted access to do things like that is what you want to do. To allow a user to commit to a particular directory, you have to give them write permission on the whole directory, so there's nothing to stop them rewriting history: deleting or editing old revisions, altering log messages, etc. I'm pretty finicky about security, because I maintain a security product and can't really afford to cut corners on the repository where its code is going to be stored.ĬVS's security model is just awful. The article is just an attempt to share my experiences: things to watch out for, how to get the most out of Subversion, that sort of thing. In general, I have found Subversion to be linearly superior to CVS and I certainly don't regret migrating to it. He was probably expecting something more like a couple of paragraphs, but I thought, hey, why not do the job right? :-) This took a fair amount of thought and effort to do well, and shortly afterwards I was asked by a colleague if I could write something about my experiences. Until November 2004, all these projects were stored in CVS, along with probably 90% of the other free software in the world. I maintain a variety of published projects, ranging from fairly major things like PuTTY to tiny little Unix utilities and I have almost as wide a variety of unpublished projects as well, ranging from half-finished major programs to my personal. When I'm not at work, I'm a free software developer. My Experiences With Subversion My Experiences With Subversion
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |