Re: Proxy target/handler access leak in Node

2018-09-17 Thread Darien Valentine
> Making is a public symbol in this manner means it is almost impossible to deny. It is still true that "util" is deniable, so this isn't necessarily fatal. I am not yet oriented enough to understand what the consequences are of suppressing util; but I am worried. I wasn’t under the impression

Re: Proxy target/handler access leak in Node

2018-09-17 Thread Mark Miller
> The Node.js trust model assumes that all code is trusted. First I want to respond to this sentence out of context. I often hear such phrases. I know what people mean by this, but the phrase "trusted" here *always* leads to confusion and muddy thinking. I don't trust the code I wrote yesterday.

Re: Proxy target/handler access leak in Node

2018-09-17 Thread Mark Miller
On Mon, Sep 17, 2018 at 8:32 AM Darien Valentine wrote: > Thanks for the context, James. Yes, this thread mainly concerns the issue > of being able to obtain references to values within the handler/target from > external code, though I did try to make a case for not having the showProxy > option

Re: Proxy target/handler access leak in Node

2018-09-17 Thread Darien Valentine
Thanks for the context, James. Yes, this thread mainly concerns the issue of being able to obtain references to values within the handler/target from external code, though I did try to make a case for not having the showProxy option in the original issue thread. I would also not have thought to

Re: Proxy target/handler access leak in Node

2018-09-17 Thread James M Snell
Some background as I am the one who added the showProxy feature into Node.js... util.inspect() is considered by Node.js to be a diagnostics API. The intent is to allow adequate debugging in a variety of scenarios. This was added to address a user issue where inspection of a Proxy object (that the

Re: Proxy target/handler access leak in Node

2018-09-16 Thread Isiah Meadows
In the browser, I could see why not to allow it by default: it's a potential security hole, and GC concerns do exist (what happens if the symbol's data is no longer accessible without reflection?). In embeddings, I'm not sure if there's any real problem, considering Node's `vm` API allows proper

Re: Proxy target/handler access leak in Node

2018-09-16 Thread Darien Valentine
> What is going on here? Can you explain? A C++/V8 API is used to obtain references to the target and handler from only the proxy object, even though those objects aren’t supposed to be available to this ES scope: https://github.com/nodejs/node/blob/master/lib/util.js#L642-L647 The pair of

Re: Proxy target/handler access leak in Node

2018-09-16 Thread Mark Miller
This is indeed quite scary. I have never used of explored the Node `util` API. What is going on here? Can you explain? The Realms shim and SES (which build on the Realms shim) create an environment in which only those globals defined by EcmaScript, not by the host, are present by default.

Re: Proxy target/handler access leak in Node

2018-09-16 Thread Mike Samuel
Nicely done! One more reason to prefer WeakMaps to properties when relating objects and secrets. On Sun, Sep 16, 2018 at 2:59 PM Darien Valentine wrote: > A few weeks ago I’d commented on an open Node github issue regarding > Proxies and inspection. While the bulk of the comment concerns an

Proxy target/handler access leak in Node

2018-09-16 Thread Darien Valentine
A few weeks ago I’d commented on an open Node github issue regarding Proxies and inspection. While the bulk of the comment concerns an opinion that proxies should not be treated as special case, I included an example of a mechanism by which the current implementation allows outside code to access