I'll retract that suggestion having tried to write an argument for it. It sad though, removing "stack" isn't really an option.
On Wed, Mar 11, 2015 at 12:03 PM, Mark S. Miller <[email protected]> wrote: > I don't understand. Could you show example code? Thanks. > > > > On Wed, Mar 11, 2015 at 12:00 PM, John Lenz <[email protected]> wrote: > >> >> >> On Tue, Mar 10, 2015 at 9:10 PM, Mark S. Miller <[email protected]> >> wrote: >> >>> On Tue, Mar 10, 2015 at 9:02 PM, Domenic Denicola <[email protected]> wrote: >>> >>>> I don’t see how any of this follows. SES can censor/remove/etc. >>>> either the .stack getter or the .getStack function. They are isomorphic. >>>> >>> >>> I can selectively provide or deny a given getStack function to different >>> code in the same realm. >>> >> >> Can't you do the same by hiding "Error" in the same way that "window" is >> hidden? Through a proxy or subclass? >> >> >>> >>> >>>> >>>> >>>> .stack already has very close to de-facto standard behavior. >>>> >>> >>> Have you looked at the case analysis I go through in debug.js to parse >>> the variety of stack formats we currently have? >>> >>> >>> >>>> We should be attempting to converge it to a standard, and not leaving >>>> it a non-interoperable mess while adding a second API. >>>> >>>> >>>> >>>> I also don’t see why .stack cannot map backward through different >>>> source maps. Again, a getter and a function are isomorphic in this regard. >>>> >>> >>> In a given realm, there can only be one Error.prototype.stack. But what >>> getStack function is in scope can differ per scope as well as per loader. >>> >>> >>> >>>> >>>> >>>> *From:* Mark S. Miller [mailto:[email protected]] >>>> *Sent:* Wednesday, March 11, 2015 12:12 >>>> *To:* Domenic Denicola >>>> *Cc:* John Lenz; es-discuss; Erik Arvidsson >>>> >>>> *Subject:* Re: Maximally minimal stack trace standardization >>>> >>>> >>>> >>>> No, that makes the std SES API non-conformant to the std API, making >>>> porting more difficult, and making it harder to write code that works in >>>> both environments. >>>> >>>> >>>> >>>> Also, if you make it look like err.stack, then no matter what you >>>> stdize, it will conflict with existing err.stack behavior, since they >>>> conflict with each other. This makes the transition more difficult. If the >>>> new std behavior looks like getStack(err), then it can be rolled out >>>> without creating a transition conflict. >>>> >>>> >>>> >>>> As so often happens, the better security is the better modularity. If >>>> you make it err.stack, then you have to make visible one canonical mapping >>>> to source positions. If you make it getStack(err), then different getStack >>>> functions might map backwards through different sourcemaps. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Mar 10, 2015 at 7:45 PM, Domenic Denicola <[email protected]> wrote: >>>> >>>> Can’t we just have Error.prototype.stack be a getter that SES is >>>> allowed to delete and hide away for its own purposes later? >>>> >>>> >>>> >>>> *From:* es-discuss [mailto:[email protected]] *On Behalf >>>> Of *John Lenz >>>> *Sent:* Wednesday, March 11, 2015 08:35 >>>> *To:* Mark S. Miller >>>> *Cc:* es-discuss; Erik Arvidsson >>>> *Subject:* Re: Maximally minimal stack trace standardization >>>> >>>> >>>> >>>> Ok, as long as we are clear there is an existing information leak on >>>> non-v8 engines. >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Mar 10, 2015 at 1:48 PM, Mark S. Miller <[email protected]> >>>> wrote: >>>> >>>> On Chrome and Opera (v8), < >>>> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js> >>>> hides the stack. It is important that we not lose this. >>>> >>>> >>>> >>>> Regarding the rest, as previously discussed, there are enough >>>> differences between browsers that there is no legacy we must codify because >>>> of web-wide agreement. Take a look at the extensive efforts < >>>> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js> >>>> makes to parse despite these differences in stack format. As long as we're >>>> standardizing something not compat with web-wide legacy, as we must, we >>>> might as well also fix this security leak in the process. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Mar 10, 2015 at 1:24 PM, John Lenz <[email protected]> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Mar 9, 2015 at 5:45 PM, Mark S. Miller <[email protected]> >>>> wrote: >>>> >>>> On Mon, Mar 9, 2015 at 5:02 PM, John Lenz <[email protected]> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Mar 9, 2015 at 12:15 PM, Mark S. Miller <[email protected]> >>>> wrote: >>>> >>>> On Sat, Mar 7, 2015 at 2:55 PM, John Lenz <[email protected]> >>>> wrote: >>>> >>>> I wanted to ping this thread and see how we could get "max-min stack >>>> traces" to the next step? >>>> >>>> >>>> >>>> Hi John, the best way to take this to the next step is to read < >>>> https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU/edit> >>>> and submit a proposal to <https://github.com/tc39/ecma262>. >>>> >>>> >>>> >>>> "If you are a TC39 member representative, just submit a pull request >>>> for your proposal." >>>> >>>> >>>> >>>> Since you are at a member organization, attend and participate actively >>>> at TC39 meetings to advance your proposal through the process. >>>> >>>> >>>> >>>> Please keep in mind that the stack trace information should not be >>>> available simply from the error object by itself, as that is a bad >>>> information leak. >>>> >>>> >>>> >>>> The threads I dug up, simply state what you state here. That there is >>>> an "information leak". Are filename and function names considered >>>> sensitive? In what way? >>>> >>>> >>>> >>>> They reveal details of the callee's computation to the caller that the >>>> callee should have been able to assume were private. See starting at middle >>>> of 2nd paragraph of < >>>> http://combex.com/papers/darpa-review/security-review.html#UniversalScope >>>> >. >>>> >>>> >>>> >>>> >>>> >>>> the depth of the execution stack is visible, which could pose a risk in >>>> certain scenarios: for instance, consider trusted code containing a >>>> recursive function whose level of recursion depends on some sensitive data >>>> (e.g., a secret cryptographic key), and suppose the recursive function is >>>> called with arguments that induce it to hit an error condition and throw an >>>> exception from deep within the recursion. In such a case, the caller might >>>> be able to learn something about the callee’s secrets by catching the >>>> exception, examining the resulting stack trace, and recovering the stack >>>> depth. These scenarios do not occur in the DarpaBrowser, but have been >>>> used in exploits on other systems. Accordingly, though the risk for >>>> DarpaBrowser is small, it should probably be repaired (Fixing this was >>>> determined not to be hard). >>>> >>>> >>>> >>>> >>>> >>>> --David Wagner and E. Dean Tribble, >>>> >>>> "A Security Review of the Combex DarpaBrowser Architecture" >>>> >>>> >>>> >>>> >>>> >>>> Likewise, the risk here -- of only a stack of function names and source >>>> positions -- is small. But it violates the normal privacy assumptions >>>> between caller and callee; and fixing it is again not hard -- via getStack. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I did not intend to promote a "rich stack inspection API" such as V8 >>>> has. >>>> >>>> >>>> >>>> That's good, but there is one thing I really like about the rich >>>> inspection API that it would be a shame to lose: The user doesn't have to >>>> do their own adhoc parsing of yet another ad hoc textual format. Since this >>>> format contains function names, we would then even need to worry about >>>> maliciously chosen function names, intended to get this stack format >>>> parsing code to misparse. If the stack is a stack of, for example, JSON >>>> strings, then we avoid this hazard. >>>> >>>> >>>> >>>> >>>> >>>> Sure, but I feel like that is independent, I mostly want to codify what >>>> already exists and standardize throw/rethrow behavior. That is why I ask >>>> about the information leak. Error objects already have "stack" properties >>>> on all the major browsers. If "stack" leaks information then they already >>>> do and the rectification should be there. (It makes no sense to add a >>>> "leak-free" API when a "leaky" one already exists). >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Cheers, >>>> --MarkM >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Cheers, >>>> --MarkM >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Cheers, >>>> --MarkM >>>> >>> >>> >>> >>> -- >>> Cheers, >>> --MarkM >>> >> >> > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
