>> 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 dcchapman_at_acm.org
> Chapman Consulting -- San Jose, CA
Received on 2011-10-02 05:27:40 CEST