<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 26, 2015 at 12:56 AM, Domenic Denicola <span dir="ltr"><<a href="mailto:d@domenic.me" target="_blank">d@domenic.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">




<div>
It's possible Reflect.construct has introduced a security hole that was not present before the recent instantiation reform. Hopefully Mark can comment more.</div></blockquote><div><br></div><div>Note that, even without `Reflect.construct`:</div><div>```</div><div>x = new C(); // C some subclass of Promise.</div><div>Object.setPrototypeOf(x, SomeArbitaryThing);</div><div>y = C.resolve(x); // doesn't actually return an instanceof C<br></div><div>```</div><div>seems somewhat surprising.  If there are security properties involved, the shortcut taken by `Promise.resolve` just seems a bit dodgy.  Better just to say `y = new C(function(r) { r(x); })` (and take the slight performance hit) if your security mechanism absolutely requires `y` to be a `C` with no funny business.</div><div>  --scott<br></div><div><br></div><div>ps. For what it's worth, my `prfun` package has what I think is a more normal use-case for `Promise.resolve` -- I define a `Promise` subclass with extra utility methods: `try`, `reduce`, `map`, `done`, and so on.  The return values from all of these methods, and for the standard `then`, `catch`, `all`, etc methods, preserve the instance type, so I know that all of the utility methods will continue to be available as I chain promises.  But at an API boundary, when `x` comes from some outside source, I use `x = PrFunPromise.resolve(x)` to ensure that the utility methods are available on x.</div><div><br></div><div>I don't need any special tamper-proofing here, so a straightforward implementation of `Promise.resolve` would work fine. Checking whether `x.__proto__ == PrFunPromise.prototype` would be ok.  But right now `[[PromiseConstructor]]` is giving me mild fits because v8 has implemented enough of the Promise spec to be storing `[[PromiseConstructor]]`, but not enough of the ES6 class mechanism for me to actually set `new.target` and `[[PromiseConstructor]]` correctly in my `PrFunPromise` subclass.  This will eventually resolve itself when the engines can implement `Reflect.construct` and/or full subclass support.  But it led me to question what `[[PromiseConstructor]]` was supposed to be doing in the first place, and whether it was doing it successfully.</div></div></div></div>