*add HTTP proxy support (I should check more before sending) On Fri, Mar 2, 2012 at 8:29 AM, Tim Caswell <[email protected]> wrote:
> 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 add 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 <[email protected]>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 [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
