Recently, I evaluated Visual SourceSafe (VSS) 6.0 for an employer. We were comparing it to other network-aware source code control systems. Visual SourceSafe is barely network aware. By "barely", it is network aware in the same way an Access Database can be network aware - all program logic is on the client side, including access control, while the server contains only data (represented as files - there is no daemon or service on the server). This in itself may not be a problem for some environments. However, the installation instructions tell the administrator to create a share for the VSS datafiles, and to give access to "Everyone" for those files. In some shops this may be acceptable, but it should not be in most. At the very least, "Authenticated Users" would be a better choice. Even better would be to limit it to those users who actually need access. Second, within a "project", you can not effectively control access. While the user interface lets you set permissions for different files, these permissions are validated by the client, not the server. Thus, anyone who reverse-engineers the client or, perhaps, anyone with access to the VSS datafiles (I'm not sure if they are encrypted; if they are, it is with a shared key hard-coded into the client) has access to the entire project. Basically, the security user interface provides a way to "advise" a client that he doesn't have access to a file. The only real security is NTFS permissions, which, unfortunately, must apply to the entire project, not individual project files/directories. To me, this is a case of "bad security is even worse then no security"! My recommendations (unless someone can provide information that what I'm seeing is wrong): 1) Lock down the share's permissions to only those with a "need to know" 2) Don't bother with the security interface of VSS 3) Put data with different security requirements in different projects 4) Note that anyone with access to those datafiles (every developer for the project!) can modify version history with custom-written tools These limitations, IMHO, makes VSS difficult to use in very large environments, although they probably don't affect a small development team much. The version history tracking cannot be used to support audit functionality, as history can be changed by a knowledgeable attacker. There is no server enforcing the rule, "Only add new versions, keep old ones" - this is done by the client. For users using the VSS client only, it is probably true. But any program could in theory access these files, including a hacker tool which allowed for changing history (for instance, to slip a bug into the next version by making it look like a particular code file has not changed in this version; thus that piece of code is not reviewed by others). For these reasons (my employer required both segregated permissions within projects and audit tracking), we were unable to use VSS, regardless of how well or poorly it actually did version tracking. I've not seen this talked about elsewhere, though, so I thought I would provide my experience to others. This is only a preliminary review - I'll post corrections if I get updated information. -- Joel Maslak
