I don't have experience with hiding source code (I tend to put everything I write on github out of habit), but I do know about keeping parts of code secure and out of the hands of anyone who might write a script using my library.
A quick example is a task I was working on at HP to ass http proxy support to nodejs services on webOS. Node services on webOS can be written by third-party developers and can contain dangerous code. WebOS sandboxes these node scripts in their own process and also inside a chroot jail. But I needed to add a new http client API that transparently used the system's proxy settings if there was one. Remember people are often behind corporate firewalls and need credentials to access the outside internet through a proxy. Now here is the dilemma. How can I give the node process the credentials without giving the user's script in the node process the credentials? We don't want third-party scripts having access to a user's corporate credentials, that would be a bad thing. There were two proposed solutions: A: Run some node code at the beginning that gets the credentials from the system while the process is still running as root, hide the credentials in a private closure with no references and drop uid so that node code later can't ask for credentials. (something like this is already used to bootstrap the chroot). Expose a public http client API that has closure access to the credentials, but doesn't give them out. B: Write a binary addon that knows how to get the credentials on demand, but only expose a http client API to the javascript. A is security through user id permissions, B is security through obscurity. If the node script was able to reverse engineer the protocol the binary addon used in B to get the credentials, it could do the same itself and publish the protocol to other users. The point is, if someone has your code, they can eventually reverse engineer what it's doing, but yes, binary addons are much harder to do this to. This problem isn't unique to node, and using binary addons is just as secure as anything else out there. Especially if the code is running a user's machine where they have full access to examine the binary's bits. On Thu, Mar 1, 2012 at 11:36 PM, Lalo Martins <lalo.mart...@gmail.com>wrote: > Well, if you can't be bothered listening to my arguments, here's the > quick answer: don't use Node. > > > best, > Lalo Martins > -- > Now go and make your dreams inevitable. > http://lalomartins.info/ > GNU: never give up freedom http://www.gnu.org/ > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
