> this, and the fact descriptors suffer inheritance which for 3 boolean > properties or a method are absolutely not helpful and make the env doomed by > `Object.prototype.writable = true` shenanigans.
Umm, those solutions are in opposition. If you seal-freeze-scotch-tape Object.prototype up, no-one's going to add `get`s, `set`s and `writable`s to it. Taking inheritance into account in defineProperty won’t then be a problem. A. On Feb 19, 2015, at 19:58, Andrea Giammarchi <[email protected]> wrote: > this, and the fact descriptors suffer inheritance which for 3 boolean > properties or a method are absolutely not helpful and make the env doomed by > `Object.prototype.writable = true` shenanigans. > > Yes, I'd personally +1 all these fixes that made these ES5 features not the > easiest one to play with > > On Thu, Feb 19, 2015 at 5:41 PM, Mark S. Miller <[email protected]> wrote: > On Thu, Feb 19, 2015 at 9:23 AM, David Bruant <[email protected]> wrote: > Hi, > > Half a million times the following meta-exchange happened on es-discuss: > - if an attacker modifies Object.prototype, then you're doomed in all sorts > of ways > - Don't let anyone modify it. Just do Object.freeze(Object.prototype)! > > I've done it on client-side projects with reasonable success. I've just tried > on a Node project and lots of dependencies started throwing errors. (I > imagine the difference is that in Node, it's easy to create projects with a > big tree of dependencies which I haven't done too much on the client side). > > I tracked down a few of these errors and they all seem to relate to the > override mistake [1]. > * In jsdom [2], trying to add a "constructor" property to an object fails > because Object.prototype.constructor is configurable: false, writable: false > * in tough-cookie [3] (which is a dependency of the popular 'request' > module), trying to set Cookie.prototype.toString fails because > Object.prototype.toString is configurable: false, writable: false > > Arguably, they could use Object.defineProperty, but they won't because it's > less natural and it'd be absurd to try to fix npm. The > Cookie.prototype.toString case is interesting. Of all the methods being > added, only toString causes a problem. Using Object.defineProperty for this > one would be an awkward inconsistency. > > > So, we're in a state where no module needs to modify Object.prototype, but I > cannot freeze it because the override mistake makes throw any script that > tries to set a toString property to an object. > Because of the override mistake, either I have to let Object.prototype > mutable (depite no module needing it to be mutable) or freeze it first hand > and not use popular modules like jsdom or request. > > It's obviously possible to replace all built-in props by accessors [4], of > course, but this is a bit ridiculous. > > It is indeed ridiculous. Not fixing this in the ES5 timeframe was my single > biggest failure and disappointment as a member of TC39. > > For reference, Caja's implementation of the technique described in [4] is at > > https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#278 > > As it states, our term for freezing an object so that it does not provoke > this problem is "tamper proofing". > > > Can the override mistake be fixed? I imagine no web compat issues would occur > since this change is about throwing less errors. > > There was a time when some of the browsers did not suffer from the override > mistake, and in so doing, were technically out of conformance with the ES5 > spec. During this window, it was clearly still web compatible to fix the > override mistake. It was during this window that I raised the issue and > argued that it be fixed. I brought this up in meetings several times and > never made any progress. Once all browsers suffered equally from the override > mistake, it was no longer *clearly* web compatible to fix it, so I gave up > and focussed on other things instead. > > However, I agree with your suspicion that it actually would still be web > compatible to fix this. Unfortunately, the only way to find out at this point > is for a browser to try deploying without the override mistake. I don't have > much hope. > > Instead, I suggest you promote tamper proofing to those audiences to which > you currently promote freezing. Though the need for it is indeed ridiculous, > it actually works rather well. We've been using it successfully for many > years now. > > > > > David > > [1] http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake > [2] > https://github.com/tmpvar/jsdom/blob/6c5fe5be8cd01e0b4e91fa96d025341aff1db291/lib/jsdom/utils.js#L65-L95 > [3] > https://github.com/goinstant/tough-cookie/blob/c66bebadd634f4ff5d8a06519f9e0e4744986ab8/lib/cookie.js#L694 > [4] > https://github.com/rwaldron/tc39-notes/blob/c61f48cea5f2339a1ec65ca89827c8cff170779b/es6/2012-07/july-25.md#fix-override-mistake-aka-the-can-put-check > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > > -- > Cheers, > --MarkM > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
