>> Ouch. If testing is done on the developer's local machine, he will need a >> full working copy and it will be impossible to restrict read access to one >> or a few files as I had planned to do with path-based authz. Instead, could >> I check out a working copy of the repository to a staging machine of mine >> and allow the developer to check out only one or a few files as defined via >> path-based authz, thereby requiring him to commit his changes and update the >> staging machine's working copy in order to test his changes and debug? I >> suppose each developer would require a separate staging machine to work this >> way. > > If a developer has access to only part of the Web site, he/she will be able > to test only part of the Web site. That is not scalable in the long run. > As soon as one part of the Web site relies on another for functioning, your > development methodology will break.
Your post has given me a lot to think about, but I don't agree that one part of the website relying on another part means the development methodology will break. Whenever something needs to be worked on, I would give the developer access to all necessary files. If it turns out I didn't grant access to enough files, I can always add one or more files to the accessible list. Can you give me an example of a situation that would break my proposed development methodology? - Grant >> I'm really getting the square peg round hole feeling. The workflow >> you describe is elegant and very enticing but it gives all of my code >> away. The prevailing attitude seems to be that developers should be >> trusted, but this goes against everything I've learned about system >> administration where security is taken seriously and trust doesn't cut >> it. I could go the NDA/NCC route but that seems only slightly more >> secure than trust to me. > > "Gives all my code away" is really an exaggeration; as soon as you have > employees (contract or otherwise), there will be more than one person who > knows the code. It is said that the most valuable assets of Silicon Valley > corporations go home at night - i.e. it is the employees and their knowledge > who are valuable, and not the source code. > > I personally know of one major corporation with a 15 million line code base > "and no one person understands all of it" (quoted from an employee). The > developers in that group can see all of the source code if they need to, but > it is their collective knowledge that keeps the program valuable and not the > source code itself. The company has NDAs and other legal agreements with > its employees and contractors, and all of them know they will be sued if > they walk away with that source code. And that is all the company can do. > > The walled-off approach can only work if the pieces are truly independent, > and that requires significant design effort up front. If your files are all > in one directory, you're just asking for a security leak (by your > definition) - one mistaken permission setting, and that secret is out. > Directory-level permissions are much easier to manage because there is only > one permission setting to track. Security is simpler when there are fewer > points of attack; a file-level system is going to be wide open. > > >> All of the big enterprise websites allow each of their developers to >> check out a full working copy of the company code with only an NDA/NCC >> to protect them? It would be so easy for any of them to use, sell, or >> give the code away, or even to accidentally allow an unauthorized >> person access to it. >> >> > > I can't speak for Web sites, but in the rest of the software world, > developers can see all of the source code for the product they are working > on. Otherwise they can't debug it; the first time a crash occurs in some > other code, the developer is dead in the water until the error can be handed > over to a responsible party. Basically, if it is in the same executable, > the developer needs to see the source code. > > It's tempting to protect your interests by blocking all access except for a > very small window, but the productivity cost is generally judged to be too > high. > > -- > David Chapman dcchap...@acm.org > Chapman Consulting -- San Jose, CA