github at esdiscuss.org (2013-07-12T02:27:37.460Z)
On Sat, Jun 15, 2013 at 10:17 AM, David Bruant <bruant.d at gmail.com> wrote: > cc'ing MarkM to get his eyes on it as I don't feel qualified to assess the > gravity. Thanks for calling my attention to this thread. Generators and multiple turns aside (see below), we've been over the security issue before but a recap is useful. The stack trace information cannot be publicly accessible from the Error object because it violates encapsulation. (Historical note: When E entered its first security review, it had this vulnerability. Thanks to David Wagner for catching it.) Instead, some sort of rights amplification is required. One possible interface is a privileged function, like the getStack function at https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#221, where getStack(err) returns the stacktrace. If you don't have the getStack function, you can't get the stacktrace. getStack is implemented using a WeakMap associating Errors with stacktraces. Another approach, if http://wiki.ecmascript.org/doku.php?id=strawman:relationships are adopted in ES7, is to have a relationship associating Error objects with stacktraces. The full read/write relationship would be internal to the implementation, but a relationship representing a readonly facet of that relationship, say @stacktrace, could be made available in the same privileged manner as getStack above. Then err at stacktrace would return the same stacktrace that getStack(err) would return above. If relationships don't happen in ES7 (it's too late for ES6) and private symbols do, then @stacktrace could be a private symbol. Multiple turn distributed debugging is indeed the next frontier, and one that will become ever more urgent as promises continue to catch on. I participated in a cool project, Causeway, that explored some of this territory well http://www.hpl.hp.com/techreports/2009/HPL-2009-78.html https://code.google.com/p/causeway/ Although the project has since been abandoned, its trace log format is a good place to start, in order to be able to support something like this in the future: http://wiki.erights.org/wiki/Causeway_Platform_Developer http://wiki.erights.org/wiki/Causeway_Platform_Developer:_Ajax http://wiki.erights.org/wiki/Causeway_Platform_Developer:_Promises https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js also provides some support for the Causeway log format. See getCWStack. See also http://crpit.com/confpapers/CRPITV135Murray.pdf and http://infoscience.epfl.ch/record/181543/files/EPFL_TH5533.pdf for other interesting approaches to extended debugging As for generators specifically, it seems to me that whatever rights amplification operation one applies to an Error object to get a stack trace, one should also be able to apply to a generator instance to get a 1-level stacktrace showing where it is currently suspended.
On Sat, Jun 15, 2013 at 10:17 AM, David Bruant <bruant.d at gmail.com> wrote: > Le 15/06/2013 11:18, Bruno Jouhier a écrit : > > A generator object represents a computation which has been suspended. We >> have an API to resume this computation (next/throw). What's missing is an >> API to get information about this suspended computation (which function, >> where in the source). >> > As an aside, note that we already have this sort of problem today with > event loop turns. > > function schedule(){ > if(Math.random() < 0.5) > throw new Error('whatever'); > else > setTimeout(schedule, Math.random()*100); > } > > setTimeout(schedule, (Math.random()*100) |0) > setTimeout(schedule, (Math.random()*100) |0) > > There is no way to know how many scheduling happened before the first > thrown error, nor whether the error comes from the first or second > scheduling originally. And that's a dummy 5-line example. It gets worse > when you have a sequence of different events (or promise resolutions) > called at different times, adding other listeners, etc. > Q solves that with long stack traces [1] (only for promises I believe). It > might be worth looking into it. > > > Back to your problem, I worry that this kind of information (a call to get > the stack trace of where the generator last yielding with line number) may > partially break encapsulation which wouldn't be good for security. > I'm thinking of something like: > > (exports => { > var someCrucialInfo = // boolean > > exports.bla = function*(){ > if(someCrucialInfo){ > doX(); > yield 27; > } > else{ > doY(); > yield 27; > } > } > })(this); > > var v = this.bla(); > var l = getLastBlaYieldLine(bla); > // given l, the encapsulated value of someCrucialInfo can be inferred > > cc'ing MarkM to get his eyes on it as I don't feel qualified to assess the > gravity. > Thanks for calling my attention to this thread. Generators and multiple turns aside (see below), we've been over the security issue before but a recap is useful. The stack trace information cannot be publicly accessible from the Error object because it violates encapsulation. (Historical note: When E entered its first security review, it had this vulnerability. Thanks to David Wagner for catching it.) Instead, some sort of rights amplification is required. One possible interface is a privileged function, like the getStack function at < https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#221>, where getStack(err) returns the stacktrace. If you don't have the getStack function, you can't get the stacktrace. getStack is implemented using a WeakMap associating Errors with stacktraces. Another approach, if < http://wiki.ecmascript.org/doku.php?id=strawman:relationships> are adopted in ES7, is to have a relationship associating Error objects with stacktraces. The full read/write relationship would be internal to the implementation, but a relationship representing a readonly facet of that relationship, say @stacktrace, could be made available in the same privileged manner as getStack above. Then err at stacktrace would return the same stacktrace that getStack(err) would return above. If relationships don't happen in ES7 (it's too late for ES6) and private symbols do, then @stacktrace could be a private symbol. Multiple turn distributed debugging is indeed the next frontier, and one that will become ever more urgent as promises continue to catch on. I participated in a cool project, Causeway, that explored some of this territory well http://www.hpl.hp.com/techreports/2009/HPL-2009-78.html https://code.google.com/p/causeway/ Although the project has since been abandoned, its trace log format is a good place to start, in order to be able to support something like this in the future: http://wiki.erights.org/wiki/Causeway_Platform_Developer http://wiki.erights.org/wiki/Causeway_Platform_Developer:_Ajax http://wiki.erights.org/wiki/Causeway_Platform_Developer:_Promises https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js also provides some support for the Causeway log format. See getCWStack. See also http://crpit.com/confpapers/CRPITV135Murray.pdf and http://infoscience.epfl.ch/record/181543/files/EPFL_TH5533.pdf for other interesting approaches to extended debugging As for generators specifically, it seems to me that whatever rights amplification operation one applies to an Error object to get a stack trace, one should also be able to apply to a generator instance to get a 1-level stacktrace showing where it is currently suspended. > oh... and we have the source code of functions by default with > Function#toString. > This sort of inference can happen in regular error stack traces too, but > requires for a function to throw which happens only if it's supposed to, > not at the caller's will. > Though I realize now that anyone holding a reference to a generator can > force an error being thrown and, if uncaught, it generates a stack trace > leaking the line number even without the API you're asking for (but that > would work only once) > > > I see this as being similar to asking for a portable "stack" property in >> Error objects. I don't know if it is actually mandated by ES6 but it looks >> like all major JS engines support it now. >> > I believe the state of TC39 on Error#stack can be found at > http://wiki.ecmascript.org/**doku.php?id=strawman:error_**stack<http://wiki.ecmascript.org/doku.php?id=strawman:error_stack> > > David > > [1] https://github.com/kriskowal/**q#long-stack-traces<https://github.com/kriskowal/q#long-stack-traces> > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130615/a962fb52/attachment.html>