Hide files from some developers

  • Thread starter Thread starter Lea
  • Start date Start date
L

Lea

Not only does my boss want to hide files from some
developers, he wants to be able to hide different files
from different users. We already use source control to
ensure that people cannot check out code that they should
not change. He wants some of the code to not be visible
to some developers.

The project is managed C++. All of the code is required
to successfully build the application. I thought to make
libraries so that code could be accessible as DLLs
through adding a reference, but these would need to be
source controlled and rebuilt when code changes. Also we
would need various libraries to hide the different parts
of the code for different people. This sounds like making
lots of places for things to go wrong.

My boss asked me "isn't there just some way you can hide
individual source code files in .Net?" I told him not to
my knowledge.

Any ideas of how I could achieve the hiding of some files
for some people in our .Net project would be appreciated.

-- Leah
 
Well working with people you trust maybe ?

Apart using DLLs I don't see how it could work (they need the source to be
able to compile, this left us with using a DLL instead of the source code).

The overall goal may help (does this code contains sensitive information or,
what ?)

Patrice
 
Hiring trustworthy employees is probably the best solution. If you
can't trust some employees with certain source, you have a big problem
on your hands.

Technically speaking your only option is to compile to DLLs and put
those is the repository. However, it's not impossible, nor even
difficult to decompile .Net binaries, so even this will not deter a
real thief.
 
Your boss has trust issues. Two bits of advice:

1) Have your boss consult a lawyer to make sure that legal agreements with
vendors and contractors are solid and can work in your company's favor in
the event of the exposure of a trade secret.

2) Create a build server that builds your app every day. Take a look at
NAnt or NMake to automate the build. Create a script to automatically copy
the results of the build to a share that allows specific access to the
employees who need it. Now, folks who need to refer to the code do not have
direct access to it.

Note that #2 is a partial victory at best. You create three issues: (a) a
loss of efficiency since a developer cannot see the code he or she is
calling, making it more difficult to use the code, (b) a sense among the
staff of distrust, which engenders resentment and lowers productivity, and
(c) no real protection of trade secrets since a developer who knows what
module the trade secret lives in can decompile the module. Of course, you
could run the code through an obfuscator during your nightly builds. This
buys you a little but not a lot.

3) Partition your systems so that key logic is only created and maintained
by internal, trusted, staff members, while other, less sensitive, work is
performed by consultants and vendors.

In Microsoft IT, we make use of consultants and vendors all the time. We
rely on #1, make use of #3, but rarely if ever use #2. No one wants to work
in an environment where they aren't wanted.

HTH,
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
 
Back
Top